[go: up one dir, main page]

WO2018066073A1 - Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations - Google Patents

Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations Download PDF

Info

Publication number
WO2018066073A1
WO2018066073A1 PCT/JP2016/079512 JP2016079512W WO2018066073A1 WO 2018066073 A1 WO2018066073 A1 WO 2018066073A1 JP 2016079512 W JP2016079512 W JP 2016079512W WO 2018066073 A1 WO2018066073 A1 WO 2018066073A1
Authority
WO
WIPO (PCT)
Prior art keywords
architecture
candidate
function
unit
functional
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2016/079512
Other languages
English (en)
Japanese (ja)
Inventor
弘樹 村野
峯岸　孝行
山本　亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2017510421A priority Critical patent/JP6173644B1/ja
Priority to PCT/JP2016/079512 priority patent/WO2018066073A1/fr
Publication of WO2018066073A1 publication Critical patent/WO2018066073A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]

Definitions

  • the present invention relates to a technology that supports architecture design in an embedded system, for example.
  • a system widely used in home appliances and office equipment is generally an embedded system composed of hardware and software.
  • the embedded system includes an ASIC (Application Specific Integrated Circuit) (or FPGA (Field-Programmable Gate Array)), a processor, a memory, and the like.
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • Patent Document 1 discloses a technique for dealing with this problem. Specifically, in Patent Document 1, the processing load of each process is calculated based on the specification describing the processing functions of the entire embedded system, the process within the threshold is executed by the processor, and the process exceeding the threshold is performed by the hardware device. A technique for performing software / hardware function division to be executed in the above is disclosed.
  • the technique of Patent Document 1 functional division is performed between a processor and a hardware device. For this reason, the technique of Patent Document 1 can only generate an architecture based on a platform in which a processor and a hardware device are connected by a bus. That is, the technique of Patent Document 1 has a problem that an architecture based on another platform such as a platform in which a plurality of hardware devices other than a processor are combined cannot be generated.
  • the main object of the present invention is to solve such problems. That is, the present invention is not limited to a combination of a processor and a hardware device, and a main object of the present invention is to obtain a configuration capable of selecting an optimal computer architecture from various architecture candidates.
  • An information processing apparatus includes: A computer architecture in which each of a plurality of functional modules extracted from the program code designates either a processor or a hardware device other than the processor as a device for realizing each functional module, and the combination of the devices is different.
  • An architecture candidate generator for generating a plurality of candidates as architecture candidates,
  • An architecture candidate selection unit that selects an architecture candidate having a required attribute required for the computer architecture from among a plurality of architecture candidates generated by the architecture candidate generation unit;
  • an optimal computer architecture can be selected from a variety of architecture candidates.
  • FIG. 3 is a diagram illustrating a functional configuration example of the architecture generation device according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of information stored in a storage unit according to the first embodiment.
  • FIG. 3 is a diagram illustrating a hardware configuration example of the architecture generation device according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of the architecture generation apparatus according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of the architecture generation apparatus according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of the architecture generation apparatus according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of a function model source code according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of a function model source code according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of a function model source code according to the first embodiment.
  • FIG. 6 is a diagram showing an example of non-functional requirement information according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a function model vector according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a non-functional requirement vector according to the first embodiment.
  • FIG. 4 is a diagram illustrating an example of functional module information according to the first embodiment.
  • FIG. 4 is a diagram showing an example of data input / output relation information according to the first embodiment.
  • FIG. 4 is a diagram showing an example of block candidates according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of an architecture candidate according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a function model vector obtained by machine learning according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a non-functional requirement vector obtained by machine learning according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of an existing architecture used in machine learning according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a grouping result obtained by machine learning according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a grouping result obtained by machine learning according to the first embodiment.
  • FIG. 1 shows a functional configuration example of the architecture generation apparatus 100 according to the first embodiment.
  • the architecture generation device 100 is connected to the high-level synthesis device 200 and the software compiler 300.
  • the architecture generation device 100 is an example of an information processing device.
  • the operation performed in the architecture generation apparatus 100 is an example of an information processing method.
  • FIG. 2 shows information stored in the storage unit 170 in the architecture generation apparatus 100.
  • FIG. 3 shows a hardware configuration example of the architecture generation apparatus 100.
  • the architecture generation device 100 is a computer including a processor 901, an auxiliary storage device 902, a memory 903, a communication device 904, an input device 905, and a display 906 as hardware.
  • the auxiliary storage device 902 includes a source code acquisition unit 110, an analysis unit 120, a functional module extraction unit 130, a block candidate extraction unit 140, an architecture candidate extraction unit 150, a performance evaluation unit 160, and an existing architecture information acquisition unit 190 illustrated in FIG.
  • a program for realizing the above functions is stored. These programs are loaded into the memory 903, and the processor 901 executes these programs.
  • the processor 901 By executing the program, the processor 901 causes a source code acquisition unit 110, an analysis unit 120, a functional module extraction unit 130, a block candidate extraction unit 140, an architecture candidate extraction unit 150, a performance evaluation unit 160, and existing architecture information to be described later.
  • the operation of the acquisition unit 190 is performed.
  • the processor 901 realizes the functions of the source code acquisition unit 110, the analysis unit 120, the functional module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition unit 190.
  • the state which is executing the program to perform is typically expressed.
  • the program that realizes the functions of the block candidate extraction unit 140, the architecture candidate extraction unit 150, and the performance evaluation unit 160 is an example of an information processing program.
  • the auxiliary storage device 902 functions as the storage unit 170 illustrated in FIG. That is, the auxiliary storage device 902 stores information shown in FIG. Further, the memory 903 may function as the storage unit 170 illustrated in FIG. That is, the memory 903 may store the information shown in FIG.
  • the communication device 904 is used when the architecture generation device 100 communicates with an external device.
  • the communication device 904 includes a receiver that receives data and a transmitter that transmits data.
  • the input device 905 is used by a user of the architecture generation device 100 to input various information to the architecture generation device 100.
  • the display 906 is used to present various information to the user of the architecture generation device 100.
  • the source code acquisition unit 110 acquires the functional model source code 171 and the non-functional requirement information 172 from the user via the input device 905.
  • the functional model source code 171 and the non-functional requirement information 172 are generated by the user of the architecture generation apparatus 100. Further, the source code acquisition unit 110 stores the acquired functional model source code 171 and the non-functional requirement information 172 in the storage unit 170.
  • FIG. 2 shows a state where the function model source code 171 and the non-functional requirement information 172 are stored by the source code acquisition unit 110.
  • the function model source code 171 is a program code in which a plurality of functions of an embedded system that is a target of architecture design is described.
  • the source code acquisition unit 110 acquires, for example, the function model source code 171 shown in FIGS. 6, 7, and 8.
  • non-functional requirement information 172 non-functional requirements that are attributes (request attributes) required for the functions described in the functional model source code 171 are described.
  • the non-functional requirement information 172 describes, for example, requirements regarding processing performance and requirements regarding circuit scale.
  • the source code acquisition unit 110 acquires, for example, non-functional requirement information 172 shown in FIG. Details of the non-functional requirement information 172 shown in FIG. 9 will be described later.
  • the analysis unit 120 divides the functional model source code 171 into minimum structural units such as functions, analyzes the number of operators, the number of branches, and the like for each minimum structural unit, and generates a functional model vector 173 indicating the analysis result. .
  • the analysis unit 120 generates the function model vector 173 shown in FIG. Details of the function model vector 173 shown in FIG. 10 will be described later.
  • the analysis unit 120 divides the non-functional requirement information 172 by a minimum unit such as a function, and generates a non-functional requirement vector 174.
  • the analysis unit 120 generates a non-functional requirement vector 174 shown in FIG. Details of the non-functional requirement vector 174 shown in FIG. 11 will be described later.
  • the analysis unit 120 also stores the generated functional model vector 173 and non-functional requirement vector 174 in the storage unit 170.
  • FIG. 2 shows a state where the functional model vector 173 and the non-functional requirement vector 174 are stored in the storage unit 170 by the analysis unit 120.
  • the functional module extraction unit 130 reads the functional model vector 173, the non-functional requirement vector 174, and the extraction rule 175 from the storage unit 170.
  • the extraction rule 175 is a rule for extracting a function module from the function model source code 171.
  • the extraction rule 175 is a rule obtained by machine learning.
  • a functional module is a set of elements that constitute the functional model source code 171.
  • the function module includes at least one function among a plurality of functions realized by the function model source code 171.
  • the function is, for example, an operation realized by a for loop block in the function model source code 171. That is, the contents described in one for loop block can be regarded as one function. However, it is left to the user of the architecture generation apparatus 100 to define what range is defined as one function.
  • the functional module extracting unit 130 extracts functional modules by grouping elements of the functional model source code 171 based on the extraction rule 175.
  • the functional module extraction unit 130 generates functional module information 176 indicating the extraction result of the functional module.
  • the functional module extraction unit 130 generates the functional module information 176 illustrated in FIG. Details of the functional module information 176 shown in FIG. 12 will be described later.
  • the functional module extraction unit 130 analyzes the data input / output relationship between the functional modules indicated in the functional module information 176 based on the functional model vector 173, and generates data input / output relationship information 177 indicating the analysis result. .
  • the functional module extraction unit 130 generates data input / output relation information 177 shown in FIG. Details of the data input / output relation information 177 shown in FIG. 13 will be described later.
  • the block candidate extraction unit 140 extracts block candidates for each functional module. More specifically, the block candidate extraction unit 140 uses a processor and a processor other than the processor as a device for realizing each functional module based on the block template 178 for each of the plurality of functional modules obtained by the functional module extraction unit 130. Specify one of the hardware devices. A device assigned to each functional module by the block candidate extraction unit 140 is referred to as a block candidate. Also, the block candidate extraction unit 140 estimates the performance and circuit scale of each block candidate, and excludes block candidates that do not match the non-functional requirements of the non-functional requirement information 172. That is, the block candidate extraction unit 140 specifies, for each functional module, a processor or hardware device having a request attribute required for each functional module as a block candidate.
  • the block candidate extraction unit 140 generates a block candidate extraction result 179 indicating the extraction result of the block candidates for each functional module.
  • the block candidate extraction unit 140 is an example of an architecture candidate generation unit together with an architecture candidate extraction unit 150 described later. Further, the process performed by the block candidate extraction unit 140 constitutes an architecture candidate generation process.
  • the architecture candidate extraction unit 150 extracts architecture candidates based on the block candidate extraction result 179 and the data input / output relation information 177. That is, the architecture candidate extraction unit 150 generates a plurality of computer architecture candidates that realize a plurality of functions included in the function model source code 171, that is, a plurality of embedded system architecture candidates, as architecture candidates. Each architecture candidate has a different combination of block candidates. Then, the block candidate extraction unit 140 generates an architecture candidate extraction result 180 indicating the extracted architecture candidate.
  • the architecture candidate extraction unit 150 is an example of an architecture candidate generation unit together with the block candidate extraction unit 140. Further, the processing performed in the architecture candidate extraction unit 150 constitutes an architecture candidate generation process.
  • the performance evaluation unit 160 performs performance evaluation of each architecture candidate indicated in the architecture candidate extraction result 180. Then, the performance evaluation unit 160 selects an architecture candidate having a required attribute required for the architecture of the embedded system from among a plurality of architecture candidates extracted by the architecture candidate extraction unit 150. More specifically, the performance evaluation unit 160 determines whether the architecture candidate satisfies the non-functional requirement indicated in the non-functional requirement information 172, and selects the architecture candidate that satisfies the non-functional requirement. Then, the performance evaluation unit 160 generates an architecture candidate selection result 181 indicating the selected architecture candidate.
  • the performance evaluation unit 160 when there is no architecture candidate that satisfies the non-functional requirement (required attribute), the performance evaluation unit 160 does not satisfy the non-functional requirement, but is the least among the plurality of architecture candidates generated by the block candidate extraction unit 140. An architecture candidate having an attribute close to the functional requirement is selected as an approximate architecture candidate. The performance evaluation unit 160 notifies the block candidate extraction unit 140 of the difference between the selected approximate architecture candidate attribute and the non-functional requirement (request attribute).
  • the performance evaluation unit 160 is an example of an architecture candidate selection unit.
  • the process performed by the performance evaluation unit 160 is an example of an architecture candidate selection process.
  • the existing architecture information acquisition unit 190 acquires existing architecture information 182 that is information on the designed architecture from the user via the input device 905. Then, the existing architecture information acquisition unit 190 stores the existing architecture information 182 in the storage unit 170. The existing architecture information 182 is used to generate the extraction rule 175.
  • the architecture generation device 100 operates in cooperation with the high-level synthesis device 200.
  • the high-level synthesis apparatus 200 automatically generates an RTL using a high-level language such as C language, C ++ language, or System C language, which has a higher abstraction level than RTL (Register Transfer Level).
  • a high-level language such as C language, C ++ language, or System C language, which has a higher abstraction level than RTL (Register Transfer Level).
  • RTL Registered Transfer Level
  • the high-level synthesis apparatus 200 can be realized by a commercially available high-level synthesis tool.
  • the architecture generation device 100 operates in cooperation with the software compiler 300.
  • the software compiler 300 outputs a binary file that can be executed by the processor of the target embedded system from the source code written in C language or the like.
  • the software compiler 300 can be realized by a commercially available compiler.
  • step S110 the source code acquisition unit 110 acquires the function model source code 171 and the non-functional requirement information 172 from the user. Then, the source code acquisition unit 110 stores the acquired functional model source code 171 and non-functional requirement information 172 in the storage unit 170.
  • the function model source code 171 is a program code describing a processing function / system configuration of the embedded system in a program language (C language or the like). 6, 7, and 8 show examples of the function model source code 171.
  • the functional model source code 171 is divided into FIG. 6, FIG. 7 and FIG. 8 for reasons of drawing, but the functional model source code 171 is one program composed of the description contents of FIG. 6, FIG. 7, and FIG. Code.
  • the function model source code 171 is the same as a general program as shown in FIGS. 6, 7, and 8, but variables corresponding to external input / output of the system are / * external_input * /, / * external_output * / It is specified.
  • DIV0 to DIV7 represent functions realized in the embedded system.
  • the functions DIV0 to DIV7 are collectively referred to as the function DIVx.
  • the non-functional requirement information 172 describes processing performance constraints and circuit scale constraints as non-functional requirements.
  • the processing performance constraint is a constraint that processing of another specific function from processing of a specific function in the function model source code 171 is completed within the time limit Tth [s].
  • Tth0 a processing performance constraint that the processing from the functions DIV0 to DIV4 is completed within 100 ⁇ s
  • a processing performance constraint Tth1 that the processing from the functions DIV5 to DIV7 are completed within 50 ⁇ s are described.
  • the circuit scale constraint is a constraint that the entire circuit scale of the embedded system realized by the function model source code is within Ath [Gate].
  • a circuit scale constraint Ath0 is described in which the total circuit scale of the embedded system is 10,000 KG.
  • the non-functional requirement information 172 may describe non-functional requirements other than processing performance constraints and circuit scale constraints.
  • the analysis unit 120 In step S120 of FIG. 4, the analysis unit 120 generates a function model vector 173 from the function model source code 171. More specifically, the analysis unit 120 divides the functional model source code 171 by the minimum division unit. In the present embodiment, the analysis unit 120 divides the function model source code 171 into functions DIV0 to DIV7 shown in FIG. 6, FIG. 7, and FIG. Next, the analysis unit 120 sets, for each function DIVx, at least one numerical parameter of the number of operators, the number of branches, the number of loops, the number of variables, and the number of data input / output included in the function model source code 171. The function model vector 173 is generated by analysis.
  • the analysis unit 120 analyzes the number of operators, the number of branches, the number of loops, the number of intermediate variables, and the number of data inputs / outputs included in the function model source code 171 for each function DIVx, and functions model A vector 173 is generated. For example, the analysis unit 120 extracts each parameter by the following method. (1) Number of Operators The analysis unit 120 obtains the number of “+”, “ ⁇ ”, “ ⁇ ”, and “ ⁇ ” included in the function DIVx. When the function DIVx includes repetition processing such as “while” and “for”, the analysis unit 120 obtains the number of repetitions ⁇ number for each operator. (2) Number of branches The analysis unit 120 obtains the number of if / else if / else included in the functional model source code 171.
  • the analysis unit 120 obtains a total value of the number of cases.
  • (3) Number of Loops The analysis unit 120 obtains the number of fore loops that are the outermost of the function DIVx.
  • (4) Number of intermediate variables The analysis unit 120 obtains the number of intermediate variables included in the function DIVx. Further, the analysis unit 120 obtains the number of variables that are not referenced or substituted by a function other than the function DIVx. (5) Number of Inputs from Outside Embedded System The analysis unit 120 obtains a total value of the number of times the variable designated by / * external_input * / is referred to in the function DIVx.
  • the analysis unit 120 obtains a total value of the number of times assigned to the variable designated by / * external_output * / in the function DIVx. (7) Number of inputs from other functions The analysis unit 120 obtains the number of variables referenced in the function DIVx. When there is a variable other than the intermediate variable in the function DIVx, the analysis unit 120 inputs from the function DIVx assigned last in the function described above the function DIVx in the function model source code 171. Count also. (8) Number of outputs to other functions The analysis unit 120 obtains the number of variables referred to in the function DIVx. When there is a variable other than the intermediate variable in the function DIVx, the analysis unit 120 also counts the number of functions DIVx + n described below the function DIVx in the function model source code 171 referring to the function DIVx. To do.
  • FIG. 10 shows an example of the function model vector 173 generated by the analysis unit 120.
  • the input field the input source function is described in a column, and the input destination function is described in a row.
  • the output destination function is described in a column, and the output source function is described in a row.
  • data is transferred from the outside to the function DIV0. Data is passed from the function DIV0 to the function DIV1.
  • Data is passed from the function DIV1 to the function DIV2 and the function DIV3.
  • Data is passed from function DIV2 to function DIV4.
  • Data is passed from the function DIV3 to the function DIV4 and the function DIV6.
  • Data is passed from the function DIV4 to the function DIV5.
  • Data is passed from the function DIV5 to the function DIV6.
  • Data is passed from the function DIV6 to the function DIV7. Further, data is transferred from the function DIV7 to the outside.
  • the function DIVx that is, the for loop block is set as the minimum division unit.
  • the minimum division unit is not limited to this, and the lowest layer function and row can be set as the minimum division unit.
  • step S ⁇ b> 121 of FIG. 4 the analysis unit 120 generates a non-functional requirement vector 174 from the non-functional requirement information 172. More specifically, the analysis unit 120 extracts a constraint value defined for the function DIVx from the non-functional requirement information 172, and generates a non-functional requirement vector 174 using the extracted constraint value.
  • the analysis unit 120 generates a non-functional requirement vector 174 as shown in FIG.
  • the processing performance constraint Tth0 is a non-functional requirement defined for the functions DIV0 to DIV4. Therefore, the analysis unit 120 sets the functions DIV0 to DIV4 to 100 ⁇ s and generates the non-functional requirement vector 174.
  • the analysis unit 120 sets 0 to the functions DIV5 to DIV7. Since the circuit scale constraint Ath is a non-functional requirement for the entire embedded system, the analysis unit 120 sets 10,000 KG for all the functions DIV0 to DIV7.
  • the non-functional requirement feedback information is information that is fed back to the performance evaluation unit 160, but the initial value is the same as the value of the non-functional requirement information.
  • step S130 the function module extraction unit 130 groups the function DIVx, and generates function module information 176. More specifically, the function module extraction unit 130 applies the extraction rule 175 to the function model vector 173 and the non-function requirement vector 174, and converts the plurality of functions DIVx included in the function model source code 171 into a plurality of function modules. Group. Then, the functional module extraction unit 130 generates functional module information 176 indicating the grouping result.
  • FIG. 12 shows an example of the function module information 176 generated by the function module extraction unit 130.
  • the function DIV0, the function DIV1, and the function DIV2 are classified into the function module 0.
  • the function DIV3 is classified into the function module 1.
  • the function DIV4 and the function DIV5 are classified into the function module 2.
  • the function DIV6 and the function DIV7 are classified into the function module 3.
  • step S131 the functional module extraction unit 130 analyzes the data input / output relationship between the functional modules, and generates data input / output relationship information 177 indicating the analysis result. More specifically, the input state and output state of data for each function indicated in the function model vector 173 are analyzed, and the input / output relationship of data between the function modules indicated in the function module information 176 is analyzed.
  • FIG. 13A shows an example of data input / output relation information.
  • FIG. 13B is a diagram schematically showing the contents shown in the data input / output relation information of FIG.
  • the block candidate extraction unit 140 extracts block candidates corresponding to the functional modules. More specifically, the block candidate extraction unit 140 extracts, as a block candidate, a block corresponding to the functional module among a plurality of blocks included in the block template 178 for each functional module.
  • the block template 178 includes a dedicated hardware device such as a processor that executes software, an ASIC, and an FPGA as a block.
  • the block template 178 includes the following information. In the following, S / W means software, and H / W means hardware.
  • (1) Processing type S / W, H / W (pipeline), H / W (parallel), H / W (sequential execution) (2) Communication type: Bus, direct connection (3) Memory type: Internal memory, external memory (volatile), external memory (non-volatile)
  • the (1) processing type is a parameter for determining whether a device that implements a functional module is a processor that executes software or a dedicated H / W.
  • H / W where pipeline processing is performed H / W where parallel processing is performed
  • H / W where sequential processing is performed are defined as types of dedicated H / W.
  • the block candidate extraction unit 140 analyzes the input / output relationship for each functional module indicated in the data input / output relationship information 177, and extracts all the blocks corresponding to each functional module as block candidates. For example, in FIG. 13, the function module 0 receives data from the outside (AXI slave), but the block candidate extraction unit 140 blocks all devices having an interface with the AXI slave from the function module 0. Extract as a candidate.
  • FIG. 14 shows an example of block candidates extracted by the block candidate extraction unit 140 for the functional module 0. In FIG. 14, block candidates 0-0, block candidates 0-1, and block candidates 0-2 are extracted.
  • step S141 the block candidate extraction unit 140 selects a block candidate that satisfies the non-functional requirement indicated in the non-functional requirement information 172 from the plurality of block candidates extracted in step S140. Then, the block candidate extraction unit 140 generates a block candidate extraction result 179 indicating the selected block candidate. More specifically, the block candidate extraction unit 140 performs high-level synthesis on a block candidate whose processing type is H / W among the plurality of block candidates extracted in step S140 by the high-level synthesis apparatus 200. The block candidate extraction unit 140 obtains block candidate performance such as processing performance and circuit scale by high-level synthesis of the high-level synthesis apparatus 200.
  • the block candidate extraction unit 140 determines for each block candidate whether or not the performance obtained by the high-level synthesis satisfies the non-functional requirements of the non-functional requirement information 172.
  • the block candidate extraction unit 140 selects a block candidate whose performance satisfies the non-functional requirement, and generates a block candidate extraction result 179 indicating the selected block candidate.
  • the block candidate extraction unit 140 performs high-level synthesis on a block candidate whose processing type is S / W among the plurality of block candidates extracted in step S140.
  • the block candidate extraction unit 140 obtains the instruction execution number and the clock number by high-level synthesis of the software compiler 300.
  • the block candidate extraction unit 140 calculates the processing performance from the number of executed instructions ⁇ the number of clocks.
  • the block candidate extraction unit 140 determines for each block candidate whether or not the calculated non-functional requirement for processing performance is satisfied.
  • the block candidate extraction unit 140 selects a block candidate whose performance satisfies the non-functional requirement, and generates a block candidate extraction result 179 indicating the selected block candidate.
  • step S150 the architecture candidate extraction unit 150 extracts the architecture candidates by connecting the block candidates selected in step S141, and generates an architecture candidate extraction result 180 indicating the architecture candidates. More specifically, the architecture candidate extraction unit 150 connects the block candidates indicated by the block candidate extraction result 179 according to the input / output relationship indicated by the data input / output relationship information 177. At this time, the architecture candidate extraction unit 150 connects the block candidates so that there is no contradiction in the communication type of each block candidate.
  • the architecture candidate extraction unit 150 connects, for example, block candidates whose communication type is the bus type to the bus.
  • FIG. 15 shows examples of architecture candidates. In the example of FIG. 15, block candidate 0-0, block candidate 0-1 and block candidate 0-2 are selected for functional module 0.
  • block candidate 1-0, block candidate 1-1, and block candidate 1-2 are selected. Further, for the functional module 2, block candidate 2-0, block candidate 2-1 and block candidate 2-2 are selected. In addition, for the functional module 3, block candidate 3-0, block candidate 3-1, and block candidate 3-2 are selected.
  • “block candidates” are simply expressed as “blocks” for reasons of drawing. In FIG. 15, only two architecture candidates are shown for reasons of drawing, but the architecture candidate extraction unit 150 selects architecture candidates corresponding to all combinations of block candidates that do not cause any contradiction in the communication type. Extract. As described above, the architecture candidate extraction unit 150 extracts a plurality of architecture candidates having different combinations of the block candidates.
  • step S160 the performance evaluation unit 160 evaluates the performance of each architecture candidate. More specifically, the performance evaluation unit 160 performs software / hardware co-simulation on each architecture candidate of the architecture candidate extraction result 180 to obtain the performance (for example, processing performance and circuit scale) of each architecture candidate.
  • step S161 the performance evaluation unit 160 determines whether the performance obtained by the software / hardware co-simulation satisfies the non-functional requirements of the non-functional requirement information 172 for each architecture candidate.
  • the performance evaluation unit 160 selects an architecture candidate having performance that satisfies the non-functional requirements from the architecture candidate extraction result 180 in step S162. . Then, the performance evaluation unit 160 generates an architecture candidate selection result 181 indicating the selected architecture candidate.
  • step S163 the performance evaluation unit 160 outputs the architecture candidate selection result 181 generated in step S162 to, for example, the display 906. Then, the architecture generation device 100 ends the process.
  • the performance evaluation unit 160 approximates that the difference between the performance and the non-functional requirements is the smallest architecture candidate in step S164. Select an architecture candidate. More specifically, the performance evaluation unit 160 calculates the absolute value of the difference between the performance obtained in step S160 and the constraint value of the non-functional requirement information 172 for each architecture candidate, and the total value of the calculated absolute values is The smallest architecture candidate is selected as an approximate architecture candidate.
  • a processing performance constraint Tth and a circuit scale constraint Ath are given as non-functional requirements.
  • the processing performance of the architecture candidate x (x is 1 to N) is the processing performance Tx
  • the circuit scale of the architecture candidate x is The circuit scale is Ax.
  • the performance evaluation unit 160 selects an architecture candidate x having a minimum value of
  • step S165 the performance evaluation unit 160 notifies the functional module extraction unit 130 of the difference between the performance of the approximate architecture candidate selected in step S164 and the constraint value. That is, the performance evaluation unit 160 notifies the functional module extraction unit 130 of the above-described
  • step S130 the functional module extraction unit 130 uses the difference (for example,
  • the difference for example,
  • the existing architecture is, for example, an architecture designed manually by a designer.
  • the architecture shown in FIG. 19 is assumed to be an existing architecture.
  • An embedded system for which an existing architecture is designed is called an existing embedded system.
  • the existing embedded system includes functions DIV0 to DIV3.
  • the function DIV0 is classified into the function module 0.
  • the function DIV1 is classified into the function module 1.
  • the function DIV2 and the function DIV3 are classified into the function module 2.
  • the functional module 0 is realized by the processor 0,
  • the functional module 1 is realized by dedicated hardware, and the functional module 2 is realized by the processor 1.
  • the processor 0, the processor 1, and the dedicated hardware are each connected to a bus, and the dedicated hardware and the processor 1 are directly connected to each other.
  • the functions DIV0 to DIV3 are collectively referred to as a function DIVx.
  • step S111 of FIG. 16 the source code acquisition unit 110 acquires the function model source code 171 and the non-functional requirement information 172.
  • the functional model source code 171 and the non-functional requirement information 172 acquired in step S111 are the functional model source code 171 and the non-functional requirement information 172 of the existing embedded system. Since the acquisition procedure in step S111 is the same as that described in step S110 of FIG. 4, the description of the acquisition procedure in step S111 is omitted.
  • the existing architecture information acquisition unit 190 acquires the existing architecture information 182 of the existing embedded system, and stores the existing architecture information 182 in the storage unit 170.
  • the existing architecture information 182 includes the following information as shown in FIG. (1) Information indicating the grouping result of the functions included in the function model source code 171 of the existing embedded system (information corresponding to the function module information 176) (2) Information on block configuration and connection between blocks in existing architecture (information corresponding to architecture candidate extraction result 180)
  • step S122 the analysis unit 120 generates a function model vector 173 from the function model source code 171 of the existing embedded system acquired in step S111.
  • the generation procedure of the function model vector 173 in step S122 is the same as that described in step S120 in FIG.
  • FIG. 17 shows an example of the function model vector 173 generated in step S122.
  • step S123 the analysis unit 120 generates a non-functional requirement vector 174 from the non-functional requirement information 172 of the existing embedded system acquired in step S111.
  • the generation procedure of the non-functional requirement vector 174 in step S123 is the same as that described in step S121 in FIG. 4, but the non-functional requirement feedback information is not used in machine learning.
  • the values of requirement feedback information are all 0.
  • FIG. 18 shows an example of the non-functional requirement vector 174 generated in step S123.
  • step S132 the function module extraction unit 130 groups the functions DIVx of the existing embedded systems based on the extraction rules 175, and generates function module information 176. Note that the generation procedure of the functional module information 176 in step S132 is the same as that described in step S130 in FIG.
  • step S133 the functional module extraction unit 130 determines whether the grouping result obtained in step S132 is equal to the grouping result included in the existing architecture information 182. If the grouping results are equal (YES in step S133), the functional module extraction unit 130 ends the process. For example, if the obtained grouping result shown in FIG. 20 is obtained in step S132, it is equal to the grouping result shown in FIG. 19, and the functional module extracting unit 130 ends the processing.
  • step S134 the functional module extraction unit 130 sets the grouping result (vector) of the existing architecture stored in the existing architecture information 182 as a correct answer, and in step S132. An error with the grouping result (vector) of the generated functional module information 176 is calculated. Then, the functional module extraction unit 130 updates the extraction rule 175 using the calculated error based on a general supervised learning algorithm or regression analysis algorithm.
  • step S134 the function module extraction unit 130 groups the function DIVx using the updated extraction rule 175 and generates new function module information 176 in step S132. Thereafter, step S133, step S134, and step S132 are repeated until the grouping results match.
  • the functional module extraction unit 130 sets the extraction rule 175 so that the grouping result shown in FIG. change. From the function model vector 173 shown in FIG. 17, since data is input from both the function DIV1 and the function DIV2 from the function DIV0, the function DIV1 and the function DIV2 can be executed in parallel. Moreover, it is predicted that the function DIV1 has a larger processing amount in the function DIV1, the function, and the DIV2 from the difference in the number of operators. For this reason, a single device is allocated to the function DIV1, and the function DIV2 and the function DIV3 share the device, whereby the circuit scale can be reduced.
  • the function module extraction unit 130 analyzes the relationship that can be read from the parameters described in the function model vector 173. Then, the functional module extraction unit 130 controls the machine learning parameter so that an error between the grouping result obtained by the extraction rule 175 and the correct grouping result is reduced from the analysis result. In this way, the functional module extraction unit 130 can generate the extraction rule 175 that can acquire the same architecture as the architecture that the designer manually generates.
  • the function module extraction unit 130 learns a plurality of existing architectures, so that the extraction rules 175 are generalized, and appropriate grouping is possible even when a function model without existing architectures and non-functional requirements are given.
  • a plurality of architecture candidates including a combination of a processor and a hardware device are generated. Therefore, an optimal computer architecture for the embedded system to be designed can be selected from various architecture candidates. .
  • the architecture generation apparatus 100 can perform processing functions for the entire embedded system without considering a platform that satisfies the non-functional requirements based on a specification in which the designer describes the processing functions for the entire embedded system. By inputting specifications and non-functional requirements describing the embedded system, it is possible to select an embedded system architecture that satisfies the non-functional requirements.
  • this invention is not limited to this Embodiment, A various change is possible as needed.
  • the functional configuration of the architecture generation apparatus 100 may be different from that shown in FIG.
  • the operation procedure of the architecture generation apparatus 100 may be different from that shown in FIGS.
  • a processor 901 illustrated in FIG. 3 is an IC (Integrated Circuit) that performs processing.
  • the processor 901 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or the like.
  • the auxiliary storage device 902 is a ROM (Read Only Memory), a flash memory, an HDD (Hard Disk Drive), or the like.
  • the memory 903 is a RAM (Random Access Memory).
  • the communication device 904 is, for example, a communication chip or a NIC (Network Interface Card).
  • the auxiliary storage device 902 also stores an OS (Operating System). At least a part of the OS is loaded into the memory 903 and executed by the processor 901.
  • the processor 901 executes at least a part of the OS while acquiring the source code acquisition unit 110, the analysis unit 120, the functional module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition A program for realizing the function of the unit 190 is executed.
  • the processor 901 executes the OS, task management, memory management, file management, communication control, and the like are performed.
  • Information and data indicating the processing results of the source code acquisition unit 110, the analysis unit 120, the functional module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition unit 190 The signal value and the variable value are stored in at least one of the auxiliary storage device 902, the memory 903, the register in the processor 901, and the cache memory.
  • the programs that realize the functions of the source code acquisition unit 110, the analysis unit 120, the function module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition unit 190 are magnetic You may memorize
  • the source code acquisition unit 110, the analysis unit 120, the function module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition unit 190 are referred to as “circuit”. Alternatively, it may be read as “step” or “procedure” or “processing”. Further, the architecture generation apparatus 100 may be realized by an electronic circuit such as a logic IC (Integrated Circuit), a GA (Gate Array), an ASIC, and an FPGA. In this case, the source code acquisition unit 110, the analysis unit 120, the functional module extraction unit 130, the block candidate extraction unit 140, the architecture candidate extraction unit 150, the performance evaluation unit 160, and the existing architecture information acquisition unit 190 are each an electronic circuit. Realized as part. The processor and the electronic circuit are also collectively referred to as a processing circuit.
  • 100 architecture generation device 110 source code acquisition unit, 120 analysis unit, 130 functional module extraction unit, 140 block candidate extraction unit, 150 architecture candidate extraction unit, 160 performance evaluation unit, 170 storage unit, 171 functional model source code, 172 non Functional requirement information, 173 functional model vector, 174 non-functional requirement vector, 175 extraction rule, 176 functional module information, 177 data input / output relation information, 178 block template, 179 block candidate extraction result, 180 architecture candidate extraction result, 181 architecture candidate
  • 182 existing architecture information 190 existing architecture information acquisition unit, 200 high-level synthesis device, 300 software compiler, 901 process Sa, 902 auxiliary memory, 903 a memory, 904 communication device, 905 input device, 906 display.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Selon l'invention, une unité de génération de candidates architectures : spécifie, pour chaque module d'une pluralité de modules de fonction extraits d'un code de programme, soit un processeur, soit un dispositif matériel autre qu'un processeur, qui doit servir de dispositif destiné à mettre en œuvre chaque module de fonction ; et génère, pour faire office de candidates architectures, une pluralité de candidates architectures d'ordinateur qui mettent en œuvre la pluralité de fonctions et ont toutes des combinaisons de dispositifs différentes. Une unité de sélection de candidate architecture sélectionne, dans la pluralité de candidates architectures générées par l'unité de génération de candidates architectures, une candidate architecture ayant des attributs requis nécessaires à l'architecture d'ordinateur.
PCT/JP2016/079512 2016-10-04 2016-10-04 Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations Ceased WO2018066073A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017510421A JP6173644B1 (ja) 2016-10-04 2016-10-04 情報処理装置、情報処理方法及び情報処理プログラム
PCT/JP2016/079512 WO2018066073A1 (fr) 2016-10-04 2016-10-04 Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/079512 WO2018066073A1 (fr) 2016-10-04 2016-10-04 Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations

Publications (1)

Publication Number Publication Date
WO2018066073A1 true WO2018066073A1 (fr) 2018-04-12

Family

ID=59505137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/079512 Ceased WO2018066073A1 (fr) 2016-10-04 2016-10-04 Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations

Country Status (2)

Country Link
JP (1) JP6173644B1 (fr)
WO (1) WO2018066073A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6752393B1 (ja) * 2019-11-19 2020-09-09 三菱電機株式会社 設計支援システムおよび設計支援プログラム
JP2022160102A (ja) * 2021-04-06 2022-10-19 三菱電機株式会社 アーキテクチャ設計支援装置およびアーキテクチャ設計支援システム
WO2023218661A1 (fr) * 2022-05-13 2023-11-16 日本電気株式会社 Dispositif d'apprentissage de conception de système, procédé d'apprentissage de conception de système et support d'enregistrement lisible par ordinateur
JP2024544114A (ja) * 2021-12-10 2024-11-28 グーグル エルエルシー ストリーミング入力データを処理するためのスケーラブルなハードウェアアーキテクチャテンプレート

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3018842A1 (fr) 2016-03-23 2017-09-28 Soliton, Inc. Systeme et procede de nettoyage cutane par ondes acoustiques pulsees
US10958521B2 (en) * 2019-07-19 2021-03-23 Oracle International Corporation Method and apparatus for configuring a cloud storage software appliance

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3958336B2 (ja) * 2005-10-03 2007-08-15 松下電器産業株式会社 インターフェースの設計方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
YOHEI KOJIMA ET AL.: "A hardware/software partitioning system with design navigation for system LSIs design", IEICE TECHNICAL REPORT, vol. 105, no. 644, 2 March 2006 (2006-03-02), pages 19 - 24 *
YOSHINORI JODAI ET AL.: "A Hardware/Software Partitioning Method for Process-level System Specification in VHDL", IEICE TECHNICAL REPORT, vol. 98, no. 449, 11 December 1998 (1998-12-11), pages 63 - 70 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6752393B1 (ja) * 2019-11-19 2020-09-09 三菱電機株式会社 設計支援システムおよび設計支援プログラム
WO2021100122A1 (fr) * 2019-11-19 2021-05-27 三菱電機株式会社 Système et programme d'aide à la conception
US11657197B2 (en) 2019-11-19 2023-05-23 Mitsubishi Electric Corporation Support system and computer readable medium
JP2022160102A (ja) * 2021-04-06 2022-10-19 三菱電機株式会社 アーキテクチャ設計支援装置およびアーキテクチャ設計支援システム
JP7528846B2 (ja) 2021-04-06 2024-08-06 三菱電機株式会社 アーキテクチャ設計支援装置およびアーキテクチャ設計支援システム
JP2024544114A (ja) * 2021-12-10 2024-11-28 グーグル エルエルシー ストリーミング入力データを処理するためのスケーラブルなハードウェアアーキテクチャテンプレート
WO2023218661A1 (fr) * 2022-05-13 2023-11-16 日本電気株式会社 Dispositif d'apprentissage de conception de système, procédé d'apprentissage de conception de système et support d'enregistrement lisible par ordinateur
JPWO2023218661A1 (fr) * 2022-05-13 2023-11-16
JP7723359B2 (ja) 2022-05-13 2025-08-14 日本電気株式会社 システム設計学習装置、システム設計学習方法、及びプログラム

Also Published As

Publication number Publication date
JPWO2018066073A1 (ja) 2018-10-04
JP6173644B1 (ja) 2017-08-02

Similar Documents

Publication Publication Date Title
JP6173644B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP6227195B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
Rushton VHDL for logic synthesis
US10025696B2 (en) System and method for equivalence class analysis-based automated requirements-based test case generation
US8302041B1 (en) Implementation flow for electronic circuit designs using choice networks
IL106139A (en) Using a state-of-the-art automaton to validate systems subject to delay constraints
KR102013582B1 (ko) 혼합 모드 프로그램의 소스 코드 오류 위치 검출 장치 및 방법
WO2015076084A1 (fr) Procédé et contrôleur pour commander le fonctionnement d'une machine
CN115454398A (zh) 一种c语言程序验证器的浮点计算精度分析方法及系统
US10990073B2 (en) Program editing device, program editing method, and computer readable medium
US20070168902A1 (en) Method for high-level synthesis of semiconductor integrated circuit
CN110020456B (zh) 利用基于图的相似性搜索逐步生成fpga实现的方法
Van Eijk Formal methods for the verification of digital circuits
US8650517B1 (en) Automatically documenting circuit designs
JP2011253253A (ja) コンピュータ試験方法、コンピュータ試験装置およびコンピュータ試験プログラム
EP3805977B1 (fr) Vérification de conception de matériel pour composant de transformation de données
US9600613B1 (en) Block-level code coverage in simulation of circuit designs
Karmazin et al. Timing driven placement for quasi delay-insensitive circuits
JP6173571B2 (ja) 回路設計装置および回路設計プログラム
Conrady et al. LCS-based automatic configuration of approximate computing parameters for fpga system designs
CN117744548A (zh) 一种芯片验证方法、装置和存储介质
KR20190059701A (ko) Devs 기반 시뮬레이션 모델 및 코드 생성 방법 및 장치
Butterfield et al. prialt in Handel-C: an operational semantics
JP5328447B2 (ja) 高位合成装置および高位合成方法、半導体集積回路の製造方法、制御プログラム、可読記憶媒体
US9251307B2 (en) Circuit information processing device, circuit information processing system, database, non-transitory computer readable medium, and circuit design method

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2017510421

Country of ref document: JP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16918272

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16918272

Country of ref document: EP

Kind code of ref document: A1