JP2008250838A - Software generation device, method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a software generation device in which porting of software is easy even on a platform with different architecture. <P>SOLUTION: A software program is composed of three kinds of components: a module which describes a process not depending on the platform by a source code [operation module], information, such as the type of the module, input/output information, process time constraint conditions [module auxiliary information], and the time constraint information of a connection configuration or the whole of the module in the software [whole configuration information]. This software generation device generates the source code suitable to the platform on which the software is executed based on the software program composed of the three kinds of components and profile information (processing time or the number of process cycles in each operation module, the access information on a memory, etc.). <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a highly portable software generation device technology, and more particularly to a software generation device technology that facilitates the porting of software to platforms of different architectures.

  2. Description of the Related Art Conventionally, a software generation device that generates a software source code by combining a module and an internal parameter for the purpose of software reuse is known. There is also known a software generation device that searches for a module based on information input by an operator and generates software by assembling the searched module. As such a prior art, for example, Patent Document 1 is known.

The software generation device according to Patent Document 1 is intended to maintain consistency between a program specification and a source program (synonymous with source code), and to accumulate a reusable program.
By using the software generation device according to Patent Document 1, software assets can be stored in the form of modules, and software can be generated efficiently by reusing the stored modules.
Japanese Patent Laid-Open No. 8-328841

However, in the software generation device shown in Patent Document 1, no consideration is given to porting to platforms with different architectures such as processor type and memory configuration, which are environments in which software operates. Therefore, even if software is generated by combining the above modules and their internal parameters, some modules may operate as they are, but the generated software generally operates on platforms with different architectures. There is a problem that it is impossible.
As described above, the software generation apparatus disclosed in Patent Document 1 has a problem that software cannot be ported on platforms having different architectures.

  In addition, the software generation apparatus disclosed in Patent Document 1 has a problem that it is not suitable for generating software that requires processing within a predetermined real time because no consideration is given to processing time. . In particular, there is a problem that it is not possible to generate software that needs to execute processing in real time, such as wireless signal processing and video signal processing.

The present invention has been made in view of such circumstances, and an object of the present invention is to provide a software generation apparatus in which software can be easily ported even on platforms having different architectures.
It is another object of the present invention to provide a software generation apparatus that can generate software that requires real-time processing.

  The present invention has been made to solve the above-described problems. The invention according to claim 1 is a platform configuration information storage unit storing memory configuration information indicating a configuration of a memory included in the platform, and the platform. An arithmetic module storage unit that stores an arithmetic module that is a source code of arithmetic processing described in a format that does not depend on the module, an auxiliary information storage unit that stores memory information used by the arithmetic module, and the arithmetic unit Computation module connection information, which is module connection information, is stored in the entire configuration information storage unit, and the computation module connection information is read out from the overall configuration information storage unit, and the computation is performed based on the readout computation module connection information. An arithmetic module order determination unit for determining the module execution order; Based on the information on the memory used by the arithmetic module read from the module supplementary information storage unit and the memory configuration information read from the platform configuration information storage unit, the memory indicated by the memory configuration information is determined as the arithmetic module order. And a software generation unit that generates and outputs a source code assigned to the operation module determined by the unit.

  Further, according to the present invention, the memory configuration information includes configuration information of a memory having different access speeds provided in the platform, and a variable used by the arithmetic module is associated with a priority of the variable as variable priority information. Variables stored in the module supplementary information storage unit and used by the software generation unit in the computation module determined by the computation module order determination unit based on variable priority order information read from the module supplementary information storage unit And generating and outputting the source code by allocating memories having different access speeds.

  In the present invention, the platform configuration information stored in the platform configuration information storage unit includes parallel execution number information that is information on the number of parallel executions that can be executed by the platform, and the software generation device includes the parallel execution number information. Execution number information is read from the platform configuration information storage unit, and the execution order of the operation modules determined by the operation module order determination unit is determined based on the execution order of the operation modules determined by the operation module order determination unit and the read parallel execution number information. A software generation apparatus comprising: a parallel processing allocation unit that determines parallel processing, wherein the software generation unit generates and outputs a source code based on a parallel execution unit.

  Further, the present invention provides the software processing time in which the entire configuration information stored in the entire configuration information storage unit is a constraint on the time for which a plurality or all of the modules configured by the arithmetic module connection information execute processing. A profiler unit that includes constraint conditions, the software generation device measures the execution time of source code corresponding to a plurality or all of the modules generated and output by the software generation unit, and generates the measured execution time as profile information And a detection unit that reads out the software processing time constraint condition from the overall configuration information storage unit and detects whether or not the execution time measured by the profiler unit satisfies the read software processing time constraint condition This is a software generation device characterized by the above.

  Further, according to the present invention, when the detection unit detects that the execution time does not satisfy the software processing time constraint condition, the detection unit and the calculation module order determination unit are configured based on the generated profile information. A software generation device characterized by repeating the process with the software generation unit.

  In the invention, the platform configuration information storage unit includes accelerator information that is information for specifying an accelerator included in the platform or library information that is information for specifying a library included in the platform. The determination unit reads the accelerator information or the library information from the platform configuration information storage unit, and one or a plurality of operations corresponding to the accelerator process specified by the read accelerator information or the process specified by the library information The module is detected as a replacement calculation module from the read calculation module connection information, and the software generation unit corresponds to the replacement calculation module detected by the calculation module order determination unit. As source code, the source code used accelerators specified by the accelerator information, or to generate a source code, using the library specified by the library information, it is a software generator apparatus according to claim.

Further, according to the present invention, the software generation device includes a compiler / linker unit that compiles and links the source code generated and output by the software generation unit. This is a software generation apparatus.
According to an eighth aspect of the present invention, when the software generation unit allocates the memory indicated by the memory configuration information to the operation module determined by the operation module order determination unit and generates and outputs a source code, the module The number of cycles required from the start of execution to the end of execution is obtained and the source code for the profile function is generated for each module as the profile function source code, and the generated profile function source code is included in the source code of the module A software generation device generating and outputting the source code.

  In addition, the present invention stores a platform configuration information storage unit that stores memory configuration information indicating the configuration of a memory included in the platform, and an arithmetic module that is a source code of arithmetic processing described in a format independent of the platform. An arithmetic module storage unit, a module-accompanying information storage unit that stores information of a memory used by the arithmetic module, and an arithmetic module connection information that is information on connection relations of the arithmetic modules A software generation method used in a software generation device having an information storage unit, wherein the software generation device reads calculation module connection information from the overall configuration information storage unit, and based on the read calculation module connection information Execution order of the arithmetic modules And the memory indicated by the memory configuration information based on the memory configuration information used by the arithmetic module read from the module supplementary information storage unit and the memory configuration information read from the platform configuration information storage unit, A software generation method characterized in that a source code is generated and output by being assigned to a determined operation module.

  In addition, the present invention stores a platform configuration information storage unit that stores memory configuration information indicating the configuration of a memory included in the platform, and an arithmetic module that is a source code of arithmetic processing described in a format independent of the platform. An arithmetic module storage unit, a module-accompanying information storage unit that stores information of a memory used by the arithmetic module, and an arithmetic module connection information that is information on connection relations of the arithmetic modules An operation for reading calculation module connection information from the overall configuration information storage unit and determining an execution order of the calculation modules based on the read calculation module connection information to a computer constituting a software generation device having an information storage unit Module order determination procedure and before Based on the information on the memory used by the arithmetic module read from the module supplementary information storage unit and the memory configuration information read from the platform configuration information storage unit, the memory indicated by the memory configuration information is determined as the arithmetic module order determination procedure. Is a software generation program for executing a software generation procedure for generating and outputting a source code by assigning to the determined operation module.

According to the present invention, there is an effect that software can be easily ported even on platforms having different architectures.
In addition, according to the present invention, it is possible to generate software that requires real-time processing.

<Overview>
First, an outline of the present embodiment will be described.
First, the software program is: (1) a module [processing module] describing processing independent of the platform in the source code, (2) information such as module type, input / output information, processing time constraint conditions [module auxiliary information], (3) Consists of three types of components: module connection configuration in software and overall time constraint information [overall configuration information].

  The software generation device is suitable for platforms that execute software based on software programs composed of these three types of components and profile information (processing time or number of processing cycles in each arithmetic module, memory access information, etc.) Generated source code (hereinafter platform-dependent source code).

At this time, the software generation apparatus uses platform configuration information (hardware configuration such as the number of cores, the number of threads, and the memory configuration) in order to generate source code (platform-dependent source code) appropriate for the platform.
The software generation device acquires profile information from a profiler described later, and generates platform-dependent source code based on the acquired profile information.

  A compiler or linker (hereinafter referred to as a compiler / linker) compiles and links platform-dependent source code using an ordinary development tool corresponding to the platform, and generates an executable file. At this time, the compiler / linker can also use the library in the same way as in normal software generation.

  The profiler acquires profile information such as the number of processing cycles (processing time) and memory access status when executing an executable file.

<First Embodiment>
Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a schematic block diagram showing a configuration of a software generation apparatus 100 according to an embodiment of the present invention.
The software generation device 100 includes a software program storage unit 10, a software generation unit 1, a platform configuration information storage unit 2, a platform-dependent source code storage unit 3, a library storage unit 4, a compiler / linker unit 5, an execution It has a file storage unit 6 and a profiler unit 7.
The software program storage unit 10 includes an arithmetic module storage unit 11, a module incidental information storage unit 12, and an overall configuration information storage unit 13.

  The software execution platform 8 is a device that is a target for executing software generated by the software generation device 100. The software execution platform 8 is, for example, a device such as a PC (personal computer) or a mobile phone. The software execution platform 8 may be the software generation device 100.

The arithmetic module storage unit 11 stores a plurality of arithmetic module source codes (hereinafter referred to as modules).
This module is source code that is the core of arithmetic processing written in a platform-independent manner. In addition, one module is constituted by a certain unit of processing.
For example, module processing includes FFT (Fast Fourier Transform) processing, turbo code processing, and the like.

  The module incidental information storage unit 12 stores a plurality of module incidental information. This module-accompanying information is associated with each module on a one-to-one basis. That is, the module and the module supplementary information are associated in advance. The module-accompanying information includes the following information about the associated module.

  This module-accompanying information includes module processing information that is module processing type, name, and summary information, module internal information that is internal information of the module, and module interface information that is information necessary for connection with other modules. , Is included.

  In addition, this module-accompanying information includes module constraint conditions that are information on constraint conditions that the module must satisfy, variable priority information that is information on variables used in the module and allocation priority to high-speed memory, etc. Is included.

For example, the module internal information includes information on the type of processing performed by the module. Further, for example, module interface information includes data type and data size information in module input / output.
Further, for example, as module constraint conditions, there is information on the constraint conditions of module processing time. Further, for example, as variable priority order information, there is information in which a variable used inside a module is associated with an assignment priority order of the variable to a high-speed memory.

The overall configuration information storage unit 13 stores overall configuration information.
The entire configuration information includes module connection information that is information indicating the entire structure of the software program configured by the module, software constraint conditions that are constraint conditions of the software program configured by the module, and the like.

  For example, the module connection information includes information indicating module connection relations. For example, as a software constraint condition, there is a software processing time constraint condition that is a constraint condition of processing time that must be satisfied by a plurality of modules or as a whole.

The platform configuration information storage unit 2 stores platform configuration information.
This platform configuration information includes core number information that is information on the number of cores provided in the platform, thread number information that is information on the number of threads that can be executed simultaneously for each core provided in the platform, and information on the memories having different access speeds provided in the platform. Memory configuration information that is information is included.

  In addition, the platform configuration information includes accelerator information that is information indicating an accelerator included in the platform, library information that is information indicating a library included in the platform, hardware configuration for direct memory access included in the platform, and settings thereof. Information such as DMA (Direct Memory Access) information is included.

Further, the accelerator information includes information such as the name of the accelerator process and setting information and source code when the accelerator is used.
Further, the library information includes information such as the name of the library processing and setting information and source code when the library is used.

In the memory configuration information, information on the speeds of memories having different access speeds and the memory capacity are stored in association with each other.
The core number information and thread number information are collectively referred to as parallel execution number information that is core number thread number information.

The software generation unit 1 (arithmetic module order determination unit) reads the arithmetic module connection information from the overall configuration information storage unit 13, and determines the execution order of the arithmetic modules based on the read arithmetic module connection information.
In addition, the software generation unit 1 performs memory based on the memory information used by the arithmetic module based on the variable priority information read from the module-accompanying information storage unit 12 and the memory configuration information read from the platform configuration information storage unit 2. A platform-dependent source code is generated by allocating a memory included in the platform indicated by the configuration information to the operation module.
In addition, the software generation unit 1 outputs the generated platform-dependent source code to the platform-dependent source code storage unit 3.

  In addition, the software generation unit 1 allocates memory having different access speeds to variables used in the operation modules for which the order has been determined based on the variable priority information read from the module supplementary information storage unit 12 to provide platform-dependent source code. Is generated.

Further, the software generation unit 1 (parallel processing allocation unit) reads the parallel execution number information from the platform configuration information storage unit 2, and executes the execution order based on the determined execution order of the arithmetic modules and the read parallel execution number information. The parallel processing of the operation module that has determined the is determined.
Further, the software generation unit 1 generates and outputs platform-dependent source code based on the arithmetic module for which parallel processing has been determined, that is, in parallel execution units. This parallel execution unit is, for example, a unit that is executed in parallel by threads for each core, as shown in FIGS. 5A to 5D described later.

  The software generation unit 1 (parallel processing allocation unit (= core thread allocation unit)) obtains the number of cores or thread number information (= parallel execution number information) from the platform configuration information storage unit 2 as information on the number of cores or the number of threads. Based on the read and determined execution order of the operation modules and the read core number thread number information, the operation modules whose execution order has been determined are assigned to the cores or threads of the platform. As a result, the software generation unit 1 determines parallel processing of the arithmetic modules that have determined the execution order.

  Further, as will be described later, the software generation unit 1 performs each module according to the execution order of the modules so that the processing amount in each core and each thread is as uniform as possible based on the profile information generated by the profiler unit 7. By assigning cores and threads to modules, platform-dependent source code that improves the execution speed of the entire software to be generated is generated.

The platform-dependent source code storage unit 3 stores the platform-dependent source code generated and output by the software generation unit 1.
The library storage unit 4 stores a library for the platform.

The compiler / linker unit 5 generates an executable file for the platform by linking and compiling the platform-dependent source code read from the platform-dependent source code storage unit 3 and the library read from the library storage unit 4. .
The compiler / linker unit 5 stores the generated executable file in the executable file storage unit 6.
The executable file generated by the compiler / linker unit 5 is stored in the executable file storage unit 6.

  The profiler unit 7 executes the execution file stored in the execution file storage unit 6, so that the entire execution file (entire module), each module, or the number of processing cycles (processing time) for a plurality of modules, Get profile information such as memory access status.

  FIG. 6 shows profile information acquired by the profiler unit 7 as an example. In FIG. 6, the processing amount (processing time) of each module occupying the whole of the modules M1 to M11 is shown as a ratio.

In addition, the profiler unit 7 outputs the acquired profile information to the software generation unit 1.
In addition, the software generation unit 1 (detection unit) is configured such that the entire execution file (entire module), the number of processing cycles (processing time) of each module or a plurality of modules, and the memory access status are module constraint conditions, software constraint conditions , It is detected whether or not a software processing time constraint condition is satisfied.
Moreover, the software generation part 1 (detection part) produces | generates a platform dependence source code again, when the detected result does not satisfy | fill all conditions.

The software generation unit 1 described above generates software for the software execution platform 8, that is, an execution file, but the information stored in the software program storage unit 10 does not depend on the software execution platform 8.
This is because the information stored in the software program storage unit 10, that is, the arithmetic module storage unit 11, the module supplementary information storage unit 12, and the overall configuration information storage unit 13 is only information about the module.

On the other hand, the platform configuration information storage unit 2 and the library storage unit 4 store platform configuration information and library information for the software execution platform 8 in advance. Therefore, the platform configuration information storage unit 2 and the library storage unit 4 depend on the software execution platform 8.
The compiler / linker 5 is also a compiler and linker for the software execution platform 8 and depends on the software execution platform 8.

The software generation unit 1, the platform-dependent source code storage unit 3, and the execution file storage unit 6 are not functionally dependent on the software execution platform 8, but the information targeted by each configuration is the software execution platform 8. Depends on.
The profiler unit 7 depends on the software execution platform 8 to acquire profile information by executing the execution file generated for the software execution platform 8. This is because, for example, the profiler unit 7 has a pseudo operating environment of the software execution platform 8 and executes the execution file in the pseudo operating environment to acquire profile information.

As described above, the arithmetic module storage unit 11, the module incidental information storage unit 12, and the overall configuration information storage unit 13 that are the software program storage unit 10 shown in FIG. 1A are platform independent. .
Also, the software generation unit 1, the platform configuration information storage unit 2, the platform-dependent source code storage unit 3, the library storage unit 4, the compiler / linker unit 5, and the execution file storage unit shown in FIG. 6 and the profiler unit 7 are platform-dependent.
The software execution platform 8 shown in FIG. 1C is the platform itself.

As described above, in the software generation device 100, the software is stored in the software program storage unit 10 in a platform-independent manner, and the platform stored in the platform configuration information storage unit 2 shown in FIG. By only changing platform-dependent information such as configuration information according to the target platform, the same software is generated as platform-dependent source code in a form that matches different platforms.
Therefore, the software generation apparatus 100 has an effect that the software can be easily ported even on platforms having different architectures.

  Conventionally, the user has created a source code corresponding to the platform-dependent source code stored in the platform-dependent source code storage unit 3 for each platform.

  On the other hand, the user who uses the software generation apparatus 100 only stores information stored in the arithmetic module storage unit 11, the module supplementary information storage unit 12, and the overall configuration information storage unit 13, that is, information about the module. Create it.

  Therefore, a user who uses the software generation apparatus 100 can create software corresponding to the platform in a form independent of the platform.

Next, the operation of the software generation unit 1 will be described with reference to FIG. First, the overall operation of the software generation unit 1 will be described with reference to the flowchart of FIG.
First, the software generation unit 1 generates platform-dependent source code (step S10).
Next, the compiler / linker unit 5 compiles and links the generated platform-dependent source code to generate an execution file (step S11).
Next, the profiler unit 7 executes the generated execution file and acquires profile information (step S12).

Next, the software generation unit 1 (detection unit) detects whether or not the acquired profile information satisfies the processing time constraint (step S13).
Next, the software generation unit 1 terminates the processing when the detected result of step S13 satisfies the processing time constraint (YES), and conversely, the acquired profile information indicates that the processing time is the processing time. If the constraint is not satisfied (NO), the processing from step S10 is repeated.

  As described above, the software generation unit 1 (detection unit) detects whether or not the acquired profile information satisfies the processing time constraint (step S13), and the acquired profile information does not satisfy the processing time constraint. In (NO), the processing from step S10 is repeated until the acquired profile information satisfies the processing time constraint, and the software generation unit 1 generates the platform-dependent source code again.

  Therefore, the software generation device 100 generates an executable file whose profile information satisfies the processing time constraint. Therefore, the software generation device 100 can generate software that requires real-time processing.

Next, the operation in step S10 in FIG. 2A, that is, the outline of the operation of the software generation unit 1 will be described with reference to the flowchart in FIG.
First, the software generation unit 1 detects the dependency relationship of the module execution order (step S21). Next, the module execution order is determined (step S22).
Next, a core and a thread are assigned to each module whose execution order has been determined (step S23). Next, memory allocation is executed for the module (step S24).
Next, platform-dependent source code is generated and output (step S25), and the process ends.

  Next, the above-described operations of the software generation unit 1 will be described in detail by taking two platforms having different specific architectures as an example. Here, the following two platforms will be described as examples of platforms having different architectures.

  [Platform A] A platform using a single core single thread processor.

  [Platform B] Platform device using a multi-core multi-thread processor (Here, as an example, a case where two cores and two threads per core can be executed in parallel will be described.)

  Further, here, as shown in FIG. 3, the module connection information is connected to the output of the module M1 and the input of the module M2, and the output of the module M1 and the input of the module M3 are connected to each other. And the input of the module M4 will be described.

  In addition, the module connection information includes an output of the module M2 and an input of the module M5, an output of the module M3 and an input of the module M5, and an output of the module M4 and an input of the module M5. Is included.

  In addition, the module connection information includes an output of the module M5 and an input of the module M6, an output of the module M6 and an input of the module M7, and an output of the module M6 and an input of the module M8. Is included.

  In addition, the module connection information includes an output of the module M7 and an input of the module M9, an output of the module M8 and an input of the module M9, and an output of the module M9 and an input of the module M10. The information that the output of the module M10 and the input of the module M11 are connected is included.

  First, in step S21, the software generation unit 1 detects the connection configuration between modules based on the module connection information of the overall configuration information (see FIG. 3).

Next, in step S22, the software generation unit 1 determines the execution order for executing module processing from the module connection configuration detected in step S21.
As an example of the method for determining the execution order, the module execution order is determined while maintaining the connection configuration as shown in FIG. 3 and the processing is divided into a plurality of modules (for example, module M2, module M3 and module As for M4, and the modules M7 and M8), the execution order of the modules is arbitrarily determined as long as there is no designation in the module incidental information or the entire configuration information.

  For example, from the connection configuration shown in FIG. 3, since only the input of the module M6 is connected to the output of the module M5, the module M5 is uniquely determined as the execution order after the module M5.

  Also, for example, from the connection configuration shown in FIG. 3, the output of the module M6 is connected to the input of the module M7 and the module M8. Module M6 may be followed by module M8. As described above, when there are a plurality of execution orders, which order is arbitrary is determined, the execution order is determined based on a random number or a module number in ascending order.

  Thereafter, in the module connection configuration as shown in FIG. 3, the execution order of the modules is determined as the order of the module numbers (numbers after M) from the module M1 to the module M11 by the process of step S22. It will be described as being done.

  Next, in step S23, the software generation unit 1 assigns cores and threads to the execution order determined in step S22. As an example of a method for allocating cores and threads, there is the following method.

  In the case of [Platform A], parallel processing of operations cannot be performed, and the processing is sequentially executed based on the execution order determined in step S22. Therefore, in this case, the modules are sequentially called and the software generation unit 1 determines a flowchart of the software program to be generated as shown in FIG.

In the case of [Platform B], a core and a thread are allocated to each module according to the execution order determined in step S22. At this time, the processing amount of each module (see FIG. 6) is acquired from the profile information, the processing amount of each core and each thread is made as uniform as possible, and adjacent processing becomes the same core as much as possible. As shown in FIG.

  As described above, the software generation unit 1 eliminates the bottleneck in the entire generated software by making the processing amount in each core and each thread as uniform as possible. It is possible to generate platform-dependent source code that makes effective use of cores. Therefore, the software generation unit 1 can generate platform-dependent source code that improves the execution speed of the entire software to be generated.

  In addition, the software generation unit 1 allocates threads so that the processing of modules adjacent to each other in the module execution order is the same core as much as possible, thereby reducing the frequency of information exchange between processes in the modules. It is possible to generate platform-dependent source code that reduces overhead due to information exchange between cores. Therefore, the software generation unit 1 can generate platform-dependent source code that improves the execution speed of the entire software to be generated.

  Here, the software generation unit 1 uses the information such as the number of modules, the size of the source code, and the object code when there is no profile information at the first time of assigning a core and a thread. In addition, a core and a thread may be allocated. For example, information such as the number of modules, the size of the source code and the object code is input to a predetermined function, and profile information is calculated. Based on the calculated profile information, a core and a thread are assigned to each module. May be assigned.

  Next, referring to FIG. 7, when the software generation unit 1 assigns a core or thread to each module in step S23, the processing amount in each core and each thread is as uniform as possible. An example method for assigning a core and a thread to each module according to the module execution order will be described.

First, a list of module execution order is generated (step S101).
Next, the thread average load is calculated (step S102). This thread average load is calculated by the following (Equation 1).

Thread average load = total module load / total number of threads (Equation 1)

Next, the processing from step S104 to step S109 described below is repeated for the number of cores (step S103 and step S110).
Next, the processing from step S105 to step S108 described below is repeated for the number of threads included in the core (steps S104 and S109).

Next, the thread load is initialized to 0 (step S105).
Next, the first module is extracted from the module execution order list and assigned to a thread (step S106).
Next, the load of the extracted module is added to the thread load (step S107).
Next, it is detected whether or not the module execution order list is empty, and whether or not the thread load is greater than the thread average load is detected (step S108).

If the detection result in step S108 indicates that the module execution order list is empty, or if the thread load is greater than the thread average load (YES), the process proceeds to the next step S109, and from step S105 described above, The process of step S108 is repeated for the number of threads included in the core (steps S104 and S109).
On the other hand, if the detection result in step S108 indicates that the module execution order list is not empty and the thread load is not greater than the thread average load (NO), the processing from step S106 is repeated.

  In addition, as another method in which the software generation unit 1 assigns the core and the thread to each module in step S23, the module processing time (processing amount) of the profile information, the module processing time constraint condition, the module connection The relationship, the amount of memory necessary for module execution, the number of cores, the number of threads for each core, and the like may be used as parameters to determine the relationship using a predetermined evaluation function.

  As described above, the software generation unit 1 determines the flowchart of the software program to be generated, for example, as shown in FIGS. 5 (a) to 5 (d).

  Next, in step S24, the software generation unit 1 executes memory allocation to the module to which the core and thread are allocated in step S23. As an example of the memory allocation, a high-speed memory free area is allocated from a variable having a high priority in a module based on the memory configuration information of the platform configuration information and the variable priority information of the module supplementary information.

Next, a method as an example of memory allocation will be described using the flowchart of FIG.
First, the variables included in the modules are sorted according to the allocation priority (step S201). Hereinafter, the variables after sorting these variables by the allocation priority will be described as a variable list varlist.

Next, the variable x having the highest priority is selected from the variables in the variable list varlist (step S202).
Next, a memory type variable memtype (hereinafter, memory type variable memtype) is set to the fastest memory (step S203).
Next, it is detected whether the remaining size of the memory indicated by the memory type variable memtype is larger than the size of the variable x (step S204).

If the detection result in step S204 indicates that the remaining size of the memory indicated by the memory type variable memtype is larger than the size of the variable x (YES), the variable x is assigned to the memory indicated by the memory type variable memtype (step S205). ).
Next, the size of the variable x is subtracted from the remaining size of the memory indicated by the memory type variable memtype (step S206).
Next, the variable x is deleted from the variable list varlist (step S207).

Next, it is detected whether or not the variable list varlist is empty (step S208).
If the detection result in step S208 indicates that the variable list varlist is empty (YES), the memory allocation is terminated.
On the other hand, if the detection result in step S208 indicates that the variable list varlist is not empty (NO), the processing from step S202 is repeated.

On the other hand, if the detection result in step S204 indicates that the remaining size of the memory indicated by the memory type variable memtype is not larger than the size of the variable x (NO), the memory is slower than the memory indicated by the memory type variable memtype. It is detected whether or not there is (step S209).
If the result of detection in step S209 is that there is no memory slower than the memory indicated by the memory type variable memtype (NO), an allocation impossible error is output (step S210). The software generation apparatus 100 that has received the unallocation error suspends software generation, for example.

  On the other hand, if the result of detection in step S209 is a memory that is slower than the memory indicated by the memory type variable memtype (YES), the memory indicated by the memory type variable memtype is then set to a high-speed memory. Then, the processing from step S204 is repeated (step S211).

  As another memory allocation method, the remaining capacity for each memory type, the time required for access, the capacity required for allocation, etc. are used as parameters, and the memory allocation is determined by a predetermined evaluation function. Also good.

After determining the memory allocation in step S24 in FIG. 2B, the software generation unit 1 outputs platform-dependent source code in step S25.
For example, the software generation unit 1 generates the source code of the interface part connecting the processing of each module in a form appropriate for the platform based on the module incidental information (module interface information) and the entire configuration information (module connection information). Then, it is combined with the module source code and output as platform dependent source code.

  Here, a case will be described in which a certain module is a module Mx, and the software generation unit 1 generates and combines the source code of the interface portion with respect to the module Mx to form a platform-dependent source code. Note that x is an arbitrary natural number.

In the case of [Platform A], the software generation unit 1 generates a platform-dependent source code that is a module call process (module Mx call process) for the module Mx.
The module Mx calling process includes a process of receiving output information from a module before the module Mx, a process of passing the received output information to the module Mx, and a process of causing the module Mx to execute a process on the received output information. , Including processing.

In the module Mx calling process, when output information is received, memory, variables, and DMA transfer are set based on the platform information and received by an appropriate method according to the platform.
The software generation unit 1 generates platform-dependent source code for the module Mx call process as described above. (See FIG. 4 (b)).

In addition, the software generation unit 1 generates platform-dependent source code that is an end process (module Mx end process) after the module process is completed (see FIG. 4B).
The module Mx end process is a process for passing output information of the module Mx to the subsequent module.

Further, in the module Mx end process, when the output information is transferred, a memory, a variable, and a DMA transfer are set based on the platform information and transferred to the platform by an appropriate method.
The software generation unit 1 generates a platform-dependent source code that is a module Mx termination process as described above. (See FIG. 4 (b)).

  Next, the software generation unit 1 adds the platform-dependent source code that is the generated module Mx call process to the top of the module Mx, and the generated platform-dependent source code that is the module Mx end process It is added at the end of Mx (see FIG. 4B).

In the case of [Platform B], as shown in FIGS. 5A to 5D, one or more modules constitute one thread, and the threads operate in parallel.
However, since each module input / output unit in the same thread is the same as in the case of the platform A, the software generation unit 1 is dependent on the platform to be the module Mx call processing for each module, as in the case of the platform A. And a platform-dependent source code for module Mx termination processing is generated (see FIG. 5E).

  In addition, the software generation unit 1 adds the platform-dependent source code that is the generated module Mx calling process to the top of the module Mx, and the platform-dependent source code that is the generated module Mx end process is added to the module Mx. (See FIG. 5E).

  Note that the software generation unit 1 does not sequentially call modules when data input / output occurs between modules across threads, but performs synchronization processing between threads and transfers data from the previous and subsequent modules. In this way, module call processing and termination processing are generated to generate source code.

  For example, the software generation unit 1 can execute the modules M2, M3, and M4 that perform parallel processing (see FIG. 3) after the output result from the module M1 is obtained. Further, the module M5 generates a calling process and a termination process for each module so that the synchronization process is performed so that the module M2, the module M3, and the output result from the module M4 are ready to be executed. , Generate source code.

  Similarly, the software generation unit 1 can execute each module M7 and module M8 that perform parallel processing (see FIG. 3) when the output result of the module M6 is obtained. M9 generates the source code by generating the calling process and termination process of each module so that it can be executed when the output results from modules M7 and M8 are ready. To do.

  In the above description, the platform configuration information has been described as being stored in advance in the platform configuration information storage unit 2 inside the software generation apparatus 100. However, the platform configuration information is not limited to this, and the platform configuration information is not limited thereto. Information may be input to the software generation apparatus 100 from the outside, and the input platform configuration information may be stored in the platform configuration information storage unit 2. For example, the software generation apparatus 100 may read a platform configuration information file.

  When the software generation device 100 stores the platform configuration information in the internal platform configuration information storage unit 2 in advance, the software generation device 100 is suitable for use as a software generation device dedicated to a specific platform. is there.

  On the other hand, when the software generation device 100 reads the platform configuration information from an external file, the software generation device 100 is suitable for use as a software generation device corresponding to a plurality of platforms.

The software generation apparatus 100 includes a compiler / linker unit 5. Therefore, the software generation apparatus 100 can perform direct compilation for the platform without outputting the platform-dependent source code as an output.
Since this software generation apparatus 100 does not go through platform-dependent source code, it is possible to directly generate an execution file that matches the platform configuration. As a result, the software generation apparatus 100 can perform more flexible and detailed control over the platform, and can generate an execution file optimal for the platform.

<Second Embodiment>
Next, a second embodiment will be described. As a second embodiment, a case will be described in which the target platform has an accelerator or a library that can be used for specific processing as compared to the first embodiment.

  In general, an accelerator or a library provided by a platform can be processed at a higher speed than a process described by source code, and can be processed with a small memory capacity in many cases. Therefore, it is desirable for the software generation apparatus 100 to actively use accelerators and libraries.

  In the second embodiment, the software generation unit 1 performs the following operation when grasping the connection configuration between modules. The software generation unit 1 refers to incidental information and overall configuration information, and if it detects that processing performed by one or more modules can be replaced by an accelerator or library of the platform, the corresponding one or more modules Instead of, decide to use an accelerator or library.

  Here, the detection of whether or not it can be replaced by an accelerator or library is performed by, for example, the module processing information module processing information read from the module incidental information storage unit 12 by the software generation unit 1 and the platform configuration information storage unit 2. The processing is executed by detecting whether or not the accelerator information or the processing name based on the library information read from the file matches.

  At this time, the software generation unit 1 does not use the source code of the module corresponding to the accelerator or library, and the processing performed by the module is performed by the accelerator or library.

  As an example, in the module call processing, platform-dependent source code is generated so as to perform input processing to an accelerator or library. Further, in the module termination process, platform-dependent source code is generated so as to perform a process of receiving output from an accelerator or a library. As a result, the processing of the software program is not changed, and higher-speed processing and processing with a small amount of memory are possible.

As an example, the software generation unit 1 generates platform-dependent source code using an accelerator or library by operating as follows.
First, the software generation unit 1 (arithmetic module order determination unit) reads the accelerator information or library information from the platform configuration information storage unit 2, and performs the accelerator process specified by the read accelerator information or the process specified by the library information. The corresponding one or more arithmetic modules are detected as replacement arithmetic modules from the read arithmetic module connection information.

  Next, the software generation unit 1 generates source code using an accelerator specified by accelerator information or source code using a library specified by library information as source code corresponding to the detected replacement operation module, Include the generated source code in the platform-dependent source code.

<Third Embodiment>
Next, a third embodiment will be described. As a third embodiment, a case will be described in which the software generation unit 1 generates a source code serving as a profiler function in the same configuration as in the first or second embodiment.

  In general, profilers include a profiler tool provided by a platform and a method of embedding source code responsible for a profile function in software. The former is often realized in such a manner that various statistical information such as the number of processing cycles and memory access frequency is collected while the software is being executed by the simulator or the like when executed on a simulator or the like.

  The latter can be used in simulators, but when running software on an actual machine, the value of the free-run counter (which is a counter that counts the operating clock cycle and instruction cycle, called the cycle counter) is set to a specific register or API. This is a mechanism for acquiring the number of cycles and the time required by the software itself by using the functions that can be acquired using.

  In the third embodiment, in order to acquire profile information of each module, the software generation device generates and outputs source code for acquiring profile information. For example, when measuring the time required for module processing, the value of the cycle counter is acquired and stored in the call processing shown in FIGS. 4B and 5E, and the cycle counter is similarly used in the end processing. Get the value of. By calculating the difference between the two counter values, the number of cycles required for the module can be obtained, and the processing time can be calculated therefrom.

  As an example, when the software generation unit 1 allocates the memory indicated by the memory configuration information to an arithmetic module and generates and outputs a source code, the software generation unit 1 obtains the number of cycles required from the start of execution of the module to the end of execution and creates a profile. A function source code is generated for each module as a profile function source code, and the generated profile function source code is included in the platform dependent source code portion of the corresponding module to generate a platform dependent source code.

According to the first to third embodiments described above, the following effects are obtained.
This has the effect of facilitating porting of software to environments with different platform architectures (processor, memory configuration, number of cores, number of threads, etc.).
In addition, since it is possible to generate software that takes into account the time required for processing, it is possible to easily port real-time signal processing software (such as audio / video signal processing software and software radio signal processing software). Play.

Also, in software development for a certain platform, it is possible to develop and execute the same software on a PC (personal computer) without using the final target platform, which improves software development efficiency. There is an effect.
In addition, because native executable files can be generated on a PC, high-speed simulation is possible without simulating the final target platform, software operation verification is facilitated, and software development efficiency is improved. .
In addition, there is an effect that it is possible to select and use the platform having the optimum processing capability at that time without changing the software.

  The platform configuration information storage unit 2, the platform-dependent source code storage unit 3, the library storage unit 4, the execution file storage unit 6, the software program storage unit 10, the arithmetic module storage unit 11, the module incidental information storage unit 12, or the whole The storage unit that is the configuration information storage unit 13 is a hard disk device, a magneto-optical disk device, a nonvolatile memory such as a flash memory, a storage medium that can only be read such as a CR-ROM, or a RAM (Random Access Memory). Volatile memory or a combination thereof.

  Further, a program for realizing the functions of the software generation unit 1, the compiler / linker unit 5 or the profiler unit 7 in FIG. 1 is recorded on a computer-readable recording medium, and the program recorded on the recording medium is recorded. The functions of the software generation unit 1, the compiler / linker unit 5, or the profiler unit 7 may be performed by being read into a computer system and executed. Here, the “computer system” includes an OS and hardware such as peripheral devices.

Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
The “computer-readable recording medium” refers to a storage device such as a flexible medium, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Furthermore, the “computer-readable recording medium” dynamically holds a program for a short time like a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. In this case, a volatile memory in a computer system serving as a server or a client in that case, and a program that holds a program for a certain period of time are also included. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.

  The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and includes design and the like within a scope not departing from the gist of the present invention.

It is a block diagram which shows the structure of the software production | generation apparatus by one Embodiment of this invention. It is a flowchart which shows operation | movement of the software production | generation apparatus of FIG. It is explanatory drawing which illustrates the connection structure of the module as an example. It is explanatory drawing which illustrates allocation of the module as an example in the case of a single core and a single thread. It is explanatory drawing which illustrates allocation of the module as an example in the case of multicore and multithread. It is explanatory drawing which illustrates the profile information as an example of a module. It is a flowchart explaining operation | movement in the case of assigning a core and a thread | sled to a module. It is a flowchart explaining operation | movement in the case of allocating a memory to the variable of a module.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Software generation part 2 Platform structure information storage part 3 Platform dependence source code storage part 4 Library storage part 5 Compiler / linker part 6 Execution file storage part 7 Profiler part 8 Software execution platform 10 Software program storage part 11 Arithmetic module storage part 12 Module Attached information storage unit 13 Overall configuration information storage unit 100 Software generation device

Claims (10)

A platform configuration information storage unit storing memory configuration information indicating the configuration of the memory included in the platform;
An arithmetic module storage unit in which an arithmetic module which is a source code of arithmetic processing described in a format independent of the platform is stored;
A module-accompanying information storage unit storing information of a memory used by the arithmetic module;
An overall configuration information storage unit storing computation module connection information, which is information on connection relations of the computation modules;
An arithmetic module order determining unit that reads arithmetic module connection information from the overall configuration information storage unit, and determines an execution order of the arithmetic modules based on the read arithmetic module connection information;
Based on the information on the memory used by the arithmetic module read from the module supplementary information storage unit and the memory configuration information read from the platform configuration information storage unit, the memory indicated by the memory configuration information is determined as the arithmetic module order. A software generation unit that generates and outputs a source code assigned to the operation module determined by the unit;
A software generation device characterized by comprising: The memory configuration information includes configuration information of a memory having different access speeds provided in the platform;
The variable used by the arithmetic module and the priority of the variable are associated with each other and stored as variable priority information in the module incidental information storage unit,
The software generator is
Based on the variable priority information read from the module-accompanying information storage unit, the source code is generated by allocating the memory having the different access speed to the variable used in the arithmetic module determined by the arithmetic module order determining unit. Output,
The software generation apparatus according to claim 1. The platform configuration information stored in the platform configuration information storage unit includes parallel execution number information that is information on the number of parallel executions that can be executed by the platform,
The software generation device is
The computation in which the execution order is read out from the platform configuration information storage unit, and the execution order is determined based on the execution order of the computation modules determined by the computation module order determination unit and the read out parallel execution number information A parallel processing allocation unit that determines parallel processing of modules,
Have
The software generator is
Generate and output source code based on parallel execution units,
The software generation apparatus according to claim 1, wherein the software generation apparatus is a software generation apparatus. The overall configuration information stored in the overall configuration information storage unit includes a software processing time constraint that is a constraint on the time at which a plurality or all of the modules configured by the arithmetic module connection information execute processing,
The software generation device is
A profiler unit that measures the execution time of source code corresponding to a plurality or all of the modules generated and output by the software generation unit, and generates the measured execution time as profile information;
A detection unit that reads out the software processing time constraint condition from the overall configuration information storage unit and detects whether or not the execution time measured by the profiler unit satisfies the read software processing time constraint condition;
The software generation apparatus according to claim 1, further comprising: The detection unit is
When the detected result does not satisfy the software processing time constraint condition for the execution time, based on the generated profile information, the processing of the arithmetic module order determination unit and the software generation unit is repeated.
The software generation apparatus according to claim 4. The platform configuration information storage unit includes accelerator information that is information for specifying an accelerator included in the platform, or library information that is information for specifying a library included in the platform,
The arithmetic module order determining unit is
The accelerator information or the library information is read from the platform configuration information storage unit, and one or a plurality of arithmetic modules corresponding to the accelerator process specified by the read accelerator information or the process specified by the library information are Detected as a replacement computation module from the readout computation module connection information,
The software generator is
Source code using an accelerator specified by the accelerator information or source code using a library specified by the library information is generated as source code corresponding to the replacement calculation module detected by the calculation module order determination unit. ,
6. The software generation apparatus according to claim 1, wherein the software generation apparatus is a software generation apparatus. The software generation device is
A compiler / linker for compiling and linking the source code generated and output by the software generation unit;
The software generation apparatus according to claim 1, further comprising: The software generator is
When the memory indicated by the memory configuration information is allocated to the arithmetic module determined by the arithmetic module order determination unit and the source code is generated and output, the number of cycles required from the start of execution of the module to the end of execution is obtained. A source code for a profile function is generated for each module as a profile function source code, the generated profile function source code is included in the source code of the module, and the source code is generated and output.
The software generation apparatus according to claim 1, wherein the software generation apparatus is a software generation apparatus. A platform configuration information storage unit storing memory configuration information indicating the configuration of the memory included in the platform;
An arithmetic module storage unit in which an arithmetic module which is a source code of arithmetic processing described in a format independent of the platform is stored;
A module-accompanying information storage unit storing information of a memory used by the arithmetic module;
An overall configuration information storage unit storing computation module connection information, which is information on connection relations of the computation modules;
A software generation method used in a software generation apparatus having
The software generation device is
Read calculation module connection information from the overall configuration information storage unit, determine the execution order of the calculation modules based on the read calculation module connection information,
Based on the memory information used by the arithmetic module read from the module-accompanying information storage unit and the memory configuration information read from the platform configuration information storage unit, the memory indicated by the memory configuration information is determined as the arithmetic module. Generate and output source code by assigning to
A software generation method characterized by the above. A platform configuration information storage unit storing memory configuration information indicating the configuration of the memory included in the platform;
An arithmetic module storage unit in which an arithmetic module which is a source code of arithmetic processing described in a format independent of the platform is stored;
A module-accompanying information storage unit storing information of a memory used by the arithmetic module;
An overall configuration information storage unit storing computation module connection information, which is information on connection relations of the computation modules;
In a computer constituting the software generation apparatus having
An arithmetic module order determination procedure for reading arithmetic module connection information from the overall configuration information storage unit and determining an execution order of the arithmetic modules based on the read arithmetic module connection information;
Based on the information on the memory used by the arithmetic module read from the module supplementary information storage unit and the memory configuration information read from the platform configuration information storage unit, the memory indicated by the memory configuration information is determined as the arithmetic module order. Software generation procedure to generate and output source code by assigning to the calculation module determined procedure,
Software generation program to execute

Images