WO2014141457A1 - 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置 - Google Patents

異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置 Download PDF

Info

Publication number
WO2014141457A1
WO2014141457A1 PCT/JP2013/057345 JP2013057345W WO2014141457A1 WO 2014141457 A1 WO2014141457 A1 WO 2014141457A1 JP 2013057345 W JP2013057345 W JP 2013057345W WO 2014141457 A1 WO2014141457 A1 WO 2014141457A1
Authority
WO
WIPO (PCT)
Prior art keywords
source code
node
output
order
input
Prior art date
Application number
PCT/JP2013/057345
Other languages
English (en)
French (fr)
Inventor
田中　和彦
小味　弘典
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2013/057345 priority Critical patent/WO2014141457A1/ja
Publication of WO2014141457A1 publication Critical patent/WO2014141457A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/327—Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist

Definitions

  • the present invention relates to a code conversion method, a code conversion program, and a code conversion apparatus between different languages.
  • the behavioral synthesis device 1 is a behavioral level description 100a for behavioral synthesis objects described in an advanced description language such as C ++, systemC, etc., and a debugging operation for behavioral synthesis described in the same advanced description language.
  • the debug signal extraction function unit 11 extracts the debug signal from the synthesis level description 100b, the trace information of the extracted debug signal is recorded on the hard disk by the signal trace information recording DB function unit 12, and the behavioral synthesis processing function unit 13 , A behavioral synthesis process is performed based on the behavioral synthesis level description 100b for debugging and the trace information, and the debugging RTL circuit generation function unit 14 generates an RTL from the behavioral synthesis result.
  • a brief description of scheduling using steps is given (see summary, etc.).
  • the present application includes a plurality of means for solving the above-mentioned object.
  • a first program language described in a first programming language in which the order in which a plurality of processes are executed is not affected by the description order of the plurality of processes.
  • the first source code A field information creation step for creating field information based on the field information creation step, a generation step for generating the second source code described in the second programming language based on the field information created in the field information creation step, and a creation step.
  • An output step for outputting the source code, and the field information includes a plurality of field information included in the first source code.
  • the input / output information indicating the input / output relationship with other nodes and the value from the node corresponding to the output of the first source code to the node corresponding to the input of the first source code are small for each node.
  • the second source code generated in the generation step has nodes having a relationship indicated in the input / output information in order from the node having the smallest substep value.
  • Example of conversion flow from verilog source to C language source Example of circuit to be converted Verilog description example of conversion target circuit
  • Example of preprocessor processed file CDFG
  • Example of tree join processing flowchart Example of CDFG after binding
  • Example of processing flow of scheduling process Example of processing flow of sched_node function Provisional substep assignment example
  • Substep number adjustment example Example of CDFG after scheduling
  • Example of CDFG after scheduling Example of generated C language source code
  • Example of header file called from generated C language source Example of code generation process flow
  • Example of processing flow of code generation processing in the second embodiment Example of processing flow of code generation processing in the third embodiment
  • Example of processing flow of code generation processing in the fourth embodiment Example of code converter configuration
  • Example of code converter configuration Example of code converter configuration
  • the data flow is extracted from the source code of the programming language to be converted, and is divided into units called steps (or cycles) corresponding to the operation clock period of the hardware description language to be converted. Performs scheduling processing. Since the length of the step can be freely set as a parameter, it is possible to easily follow changes such as the clock frequency.
  • Such a merit can be obtained by using behavioral synthesis, but in order to perform behavioral synthesis, a source code in which a target function is described in a programming language is required. However, when the clock frequency of an existing LSI is changed, the target function is already described in the hardware description language, and there are often no source codes described in the programming language. In such a case, it is convenient to have a tool for converting in the reverse direction to behavioral synthesis, that is, converting source code described in a hardware description language into source code described in a programming language.
  • the hardware description language is a parallel processing language, and each operation is processed at the same time. Therefore, with some exceptions, the processing description order does not affect the result.
  • the verilog language which is one of the hardware description languages
  • “assign a 10;” which is a process of substituting 10 for the signal a
  • “assign b a” which is a process of substituting the value of the signal a for the signal b. ; ”Is described, 10 is assigned to both a and b regardless of which one is described first.
  • 10 is assigned to both the variable a and the variable b, but if written in the reverse order, The value (for example, 1) stored in a before substituting 10 is substituted into b, and 10 is substituted into variable a and 1 is substituted into variable b.
  • a data flow is divided into a plurality of steps by a register and a scheduling process is performed.
  • the present invention introduces a virtual time unit called a sub-step obtained by further dividing a step corresponding to a clock cycle. Regardless of the type of each node on the data flow, a substep number is assigned to each node, assuming that one substep time is used for processing. After that, by sequentially converting the node with the small substep number into the source code of the programming language, the description order of each process can be determined while maintaining the dependency in the original source code. Since the substep number is given for the sake of convenience, by setting the substep number in the reverse order to that described below, the target source code is converted sequentially from the node with the larger substep number. It is also possible to obtain.
  • FIG. 24 is an example of the code conversion apparatus 1 according to the first embodiment.
  • the code conversion apparatus 1 includes a preprocessor processing unit 600, a lexical analysis processing unit 601, a syntax analysis processing unit 602, a tree join processing unit 603, a scheduling processing unit 604, an optimization processing unit 605, and a code generation processing unit.
  • CPU 610, memory 611, recording unit 612, input unit 613, and output unit 614 are connected via a bus 614.
  • the preprocessor processing unit 600, the axis analysis processing unit 601, the syntax analysis processing unit 602, the tree join processing unit 603, the scheduling processing unit 604, the optimization processing unit 605, and the code generation processing unit 606 are shown in FIG. As illustrated, the code conversion device 1 can be installed as hardware.
  • Each of the processing units 600 to 606 includes a preprocessor program 600, a lexical analysis program 601, a syntax analysis program 602, a tree combination program 603, a scheduling program 604, and an optimization program 605 recorded in the recording unit 612.
  • the code generation program 606 may be installed in the code conversion apparatus 1 as software so that the CPU 610 expands the code 606 in the memory 611 and the CPU 610 executes the expanded programs so that the function of each processing unit is exhibited.
  • each processing unit will be described as performing each processing mainly. Note that when each processing unit is realized by software, each processing unit realized by the CPU 610 executing the various programs will be described as the main body of each processing.
  • the preprocessor processing unit 600 performs preprocessor processing such as macro replacement and comment removal from the input source and header file.
  • the lexical analysis processing unit 601 performs lexical analysis processing on the preprocessor-processed file and divides it into units called tokens.
  • a token is a character string of the smallest unit that does not have its original meaning if it is further divided.
  • the syntax analysis processing unit 602 performs syntax analysis processing.
  • the parsing process is a process of generating a CDFG tree that is a partial CDFG structure from a token sequence corresponding to each line (or a block that is a block of several lines) of the verilog source code.
  • the tree join processing unit 603 performs a tree join process.
  • the tree combining process is a process of combining a plurality of CDFG trees into one CDFG.
  • the scheduling processing unit 604 performs ordering of each node, that is, scheduling processing in order to sequentially convert each node into a C language source code while maintaining the dependency of each processing.
  • the optimization processing unit 605 performs optimization processing for improving the processing performance of the generated C language source code.
  • the code generation processing unit 606 performs code generation processing that replaces the scheduled CDFG with the corresponding C language source code in the order of the substep numbers.
  • FIG. 1 shows a conversion flow from a source code described in a hardware description language to a source code described in a programming language in this embodiment.
  • step 501 is expressed as S501.
  • C language is described as an example where verilog is a programming language as a hardware description language, but the present invention is not limited to this combination, and a sequential processing type description from a parallel processing type description language. Can generally be used for conversion to language.
  • FIG. 2 shows a circuit to be converted in this embodiment.
  • the conversion target circuit 20 includes a multiplier 21, adders 22 and 25, and flip-flops 23 and 24.
  • the flip-flops 23 and 24 operate at the rising edge of the clock signal clk, and the output is reset to 0 when the asynchronous reset signal rst_n is set to the Low level.
  • the circuit 20 is divided into two pipeline stages by flip-flops 23 and 24.
  • the left side of the flip-flops 23 and 24 is stage 0, and the right side is stage 1. Stages are sometimes expressed in terms of steps in the field of behavioral synthesis.
  • FIG. 3 shows an example in which this circuit is described in verilog.
  • the numbers on the left are line numbers and are not included in the source code. Since this list conforms to verilog, detailed description of each part will be omitted.
  • FIG. 4 shows a header file read by the include statement on the second line in FIG.
  • the header failure contains macro definitions.
  • the verilog source code 10 and the header file 11 are subject to conversion processing in this embodiment.
  • both the source code 10 and the header file 11 are realized by a single file, but may be constituted by a plurality of files or the header file 11 may not exist. .
  • the preprocessor processing unit 600 reads the verilog source code 10 and the header file 11, and performs processing such as macro replacement and comment removal.
  • An example of the preprocessor-processed file 12 that is the output of the preprocessor process S500 is shown in FIG.
  • FIG. 6 shows an example of the structure of CDFG.
  • FIG. 6A is a verilog source code to be converted in this example, and corresponds to the assign statement on the 32nd line in FIG. According to this verilog source code, after the signals a [15: 0] and b [15: 0] are multiplied, the signal x [15: 0] is added to the value obtained as a result of the multiplication. Has been.
  • FIG. 6 (b) is obtained by converting the verilog source code of FIG. 6 (a) into CDFG.
  • each process to be executed is represented by a node, and each node is connected by an arrow having a direction to form a graph structure as shown in FIG.
  • FIG. 6C shows an example of CDFG structure field information.
  • attribute information 40 for each node is stored.
  • the attribute information 40 includes an ID number 41, a node type 42, a signal name 43, bus information 44, inputs 45 to 47, st48, and sst49.
  • CDFG may be implemented by any method, but here it is implemented as a set of C language structures having a link structure.
  • signals a [15: 0], b [15: 0], and x [15: 0] correspond to the nodes 30, 31, and 32, respectively.
  • ID numbers 41 are assigned to these nodes as “1”, “2”, “3”, and the node type 42 is an identifier such as a signal name. It is “ID” indicating that there is.
  • the multiplication in the verilog source in FIG. 6A corresponds to the node 33, and the addition corresponds to the node 34.
  • the ID numbers 41 of the nodes 33 and 34 are “4” and “5”, respectively, and the type 42 is stored as “MULT” indicating multiplication and “ADD” indicating addition. .
  • the signals a [15: 0] and b [15: 0] are applied to the inputs 0 and 1 of the node 33, respectively.
  • ID numbers “1” and “2” indicating “” are stored as link information.
  • the ID numbers “4” and “3” indicating the node 33 and the node 32 are stored as link information in the inputs 0 and 1, respectively.
  • the output signal name s of the node 34 is specified by the verilog source code of FIG.
  • st48 and sst49 in this table mean steps and sub-steps, respectively.
  • the step is a concept corresponding to the pipeline stage in FIG.
  • the sub-step is a unit obtained by further subdividing the step, and details will be described later.
  • the value of the sub-step is determined in the scheduling process S504, and is not fixed at the time point before that, and is described as “ ⁇ ” in FIG. 6C. If CDFG is used in this way, it is possible to express data flow and control flow.
  • FIG. 7 is an explanatory diagram of lexical analysis and syntax analysis.
  • FIG. 8 is an explanatory diagram of syntax analysis and CDFG generation.
  • the preprocessor-processed file 12 is divided into units called tokens in the lexical analysis processing 501 by the lexical analysis processing unit 601.
  • Lex is famous as a tool for performing the lexical analysis processing S501, and the lexical analysis processing S501 in the present embodiment can also be realized by using lex. Since the usage is described in various documents, description thereof is omitted here.
  • a tool other than lex can be used, and the present invention is not limited to the case where lex is used.
  • syntax analysis processing unit 602 performs syntax analysis processing S502 on the token string obtained in the lexical analysis processing 501.
  • famous yacc is used as a syntax analysis tool.
  • a tool other than yacc can be used as described above, and the present invention is not limited to this. Absent.
  • the syntax of the language to be processed is prepared in advance as pattern information, and pattern matching is performed sequentially on the token strings. If they match, the rules defined in advance are supported. It will be in the form of performing processing.
  • matching is performed while sequentially scanning the given token sequence from the left, and the token sequence s [15: 0] is matched first (matching 50).
  • a rule is specified so as to generate a node whose node type is ID
  • a node s is generated as in the matching 50 of FIG.
  • node a and node b are generated by matching 51 and 52.
  • a multiplication node is generated and connected to the nodes a and b.
  • a node x is generated, and in the next matching 55, an addition node is generated and connected to the multiplication node and the node x.
  • the node on the left side and the node on the right side are joined by matching 56 to complete the CDFG tree corresponding to this row.
  • FIG. 9 is an example of a plurality of CDFG trees generated by sequentially performing the lexical analysis processing S501 and the syntax analysis processing S502 on the other lines of FIG.
  • the input / output port definitions on lines 9 to 15 in FIG. 5 are converted to the input / output nodes in FIG. 9 (a).
  • the node type 42 of the input signal is “IN”
  • the node type 42 of the output signal is “OUT”.
  • Bidirectional input / output ports are described by dividing them into two ports with node types 42 of “IN” and “OUT”.
  • the flip-flop description on lines 21 to 30 in FIG. 5 is converted as shown in FIG. 9B.
  • the flip-flop is expressed by two nodes on the input side and the output side, and the respective node types 42 are “FF0” and “FF1”.
  • the value of “FF0” is transferred to “FF1” at the rising edge of the clock.
  • the tree join processing unit 603 performs a tree join process S503. However, not all nodes are necessarily integrated into one CDFG. This process is a process of deleting a node whose node type is ID in each CDFG tree of FIG. 9 and switching to the original link destination.
  • FIG. 10 is an example of a flowchart of the tree joining process.
  • step 701 is expressed as S701.
  • a variable i for designating the ID number of each node is initialized to 0 (S702).
  • a node i whose node ID number is equal to i is searched for, and the node information is read (S703).
  • the original link destination is searched.
  • a variable j for designating the ID number of the link destination node is initialized to 0 (S705).
  • a node j whose node ID number is equal to j is searched for, and the node information is read (S706).
  • node j If the type of node j is not ID, OUT, or FF0, the signal names of node i and node j are compared (S708). If both are equal, node j is the original link destination, so all the nodes are scanned, and the link destination of the link whose link destination is node i is changed to all nodes j (S711). Thereafter, by deleting the node i, the node link destination changing process is completed. In S708, if the signal names do not match, the processing from S709 to S710 is performed.
  • FIG. 11 shows the result of performing the tree join processing S503 for all the nodes in FIG.
  • “Scheduling” here refers to scheduling that is a finer unit than the scheduling in units of clock cycles such as steps used in behavioral synthesis, and in order to realize this, a virtual time unit called a substep is introduced here.
  • a step may be abbreviated as st and a sub step may be abbreviated as sst.
  • scheduling is performed on the assumption that each node uses a time corresponding to one substep for execution of processing regardless of the node type.
  • FIG. 12 is an example of the overall flow of the scheduling process S504.
  • FIG. 13 is an example of a processing flow of the function sched_node that is recursively called from S725 in the flow of FIG.
  • the scheduling process S504 can be divided into a first half process for setting a temporary substep number for each node and a second half process for adjusting a temporary substep number to determine a final substep number.
  • Substep number 0 is set for the output node (OUT) and the input node (FF0) of FF.
  • the process 2 is recursively executed while sequentially tracing the nodes to the input side.
  • the first half (S722 to S727) of the scheduling process S504 in FIG. 12 corresponds to the process “1.”, and the function “sched_node” in FIG. 13 is recursively called and executed as the process “2.”.
  • the substep number to be set for the target node as one of the arguments.
  • the example in FIG. 13 assumes a case where the number of inputs at each node is three at the maximum, but the present invention is not limited to this.
  • FIG. 14 is an example of a state in which a temporary substep number is set for each node of the CDFG in FIG. 11 by the above procedure.
  • the numbers enclosed in pentagons are the substep numbers of each node. Since the sub step number is set while sequentially subtracting 1 from “0”, the sub step number is a number equal to or less than “0”.
  • the sub-step number of the node 40 is “ ⁇ 1” when the node 43 is traced and “ ⁇ 2” when the node 42 or 44 is traced. However, the sub-step number is finally determined by the processing of S732 to S734 in the function sched_node. “ ⁇ 2” which is the smallest value is set.
  • S760 and S761 performed at the beginning of the second half of the scheduling process 504 are processes for setting all substep numbers to a value of “0” or more.
  • S760 is a process of searching for the smallest value (sst_min) among all the substep numbers.
  • sst_min the smallest value
  • sst_min ⁇ 3
  • S761 the value of sst_min is subtracted from the value of the sub step number for all nodes.
  • FIG. 15 is an example of the result of performing the above processing on the CDFG of FIG.
  • S762 is performed, and the sub-step number of the input node and the output node (FF1) of FF is set to 0.
  • This processing is not essential, but there is an advantage that the illustrated CDFG and the generated C language source code can be easily seen by aligning the input and flip-flop update timings.
  • FIG. 16 is an example of CDFG in which the CDFG after S762 is arranged so that the same substep numbers are arranged in the same column, and the nodes having the same step number are grouped and rewritten. This is the CDFG in the state where the scheduling process S504 is completed.
  • FIG. 17 shows the field information of the CDFG structure after scheduling of the portion corresponding to FIG. Compared with FIG. 6C, it can be seen that the value of sst is stored and that the top three nodes are replaced with the combined nodes by the tree combination processing. Since the step number and substep number are held in the CDFG in this way, the source code of the hardware description language is generated from the step number from here, or the source code of the programming language is used by using the substep number. And the CDFG can serve as a language conversion hub.
  • the optimization processing S505 is processing performed by the optimization processing unit 605 in order to improve the processing performance of the generated C language source code, and the processing order is changed within a range that does not affect the execution result ( For example, the outer loop and the inner loop can be interchanged), the process can be replaced (division is replaced by a shift), and the like.
  • the optimization process S505 need not be executed unless particularly necessary. .
  • the code generation processing S506 performed by the code generation processing unit 606 is processing for replacing the scheduled CDFG with the corresponding C language source code in the order of the substep numbers.
  • FIG. 18 shows an example in which the CDFG in FIG. 16 is converted into C language source code
  • FIG. 19 shows an example of a header file referenced from the C language source code.
  • header information When generating C language source code, first, header information and a function name are output (S781). The first to fourth lines in FIG. 18 are output by this processing.
  • the header information includes a comment and a necessary header file read command.
  • output the I / O signal definition This corresponds to the argument description of the function on the 5th to 10th lines in FIG.
  • the output signal is a pointer variable so that the result value can be returned to the function caller.
  • the function body is output in the order of the substep numbers.
  • the variable sst is set to 0 (S785), and nodes whose substep numbers are equal to the value of the variable sst are sequentially output according to the C language grammar rules (S786).
  • the node 33 in FIG. 16 is output as in the 25th line in FIG. Since the signal name of the node 33 is not defined, the automatically generated internal signal name t_0000 is used as the value on the left side.
  • the flip-flop distinguishes the two by preparing variables with _0 and _1 added to the signal names on the input side and the output side, respectively. Prior to execution, the flip-flop has substep number 0, and the output side variable is assigned to the input side. By assigning to a variable, the operation as a flip-flop is realized in which data is transferred at a clock edge.
  • bit width of variables often supports only discrete values such as 8, 16, and 32, but hardware languages often support arbitrary bit widths. This difference can be dealt with by preparing a macro as shown in FIG.
  • the C language function generated in this way is called from the main function by setting a value corresponding to the actual input signal value as an argument of the function for each clock, so that the same result as the circuit described in the original verilog is obtained. You will be able to get
  • conversion from verilog to C language is performed all at once, but it is possible to increase the flexibility by dividing the processing by outputting the contents of CDFG to a file as an intermediate result. This will be described with reference to FIG.
  • the verilog-CDFG conversion S50 and the CDFG-C language conversion S52 are the same processing as in the first embodiment.
  • VHDL is widely used as a hardware description language.
  • VHDL-CDFG conversion S51 By adding VHDL-CDFG conversion S51 to this conversion flow, conversion from VHDL to C language is also possible.
  • the VHDL-CDFG conversion S51 and the verilog-CDFG conversion S50 have the same basic structure although there are fine differences.
  • CDFG-C language conversion S52 can be shared by the conversion from verilog and the conversion from VHDL, it is advantageous in terms of the development man-hours of the conversion tool.
  • CDFG-C ++ language conversion S55 when the destination programming language is a language other than C language such as C ++, it is only necessary to add CDFG-C ++ language conversion S55. Regarding the conversion processing from the hardware description language in the first half to CDFG, It can be used as it is. Since the basic structures of the CDFG-C ++ language conversion S55 and the CDFG-C language conversion S52 are the same, a detailed description thereof is omitted.
  • the scheduling process S504 and the optimization process S505 are separately prepared for the C language output and the C ++ language output, but the scheduling process S504 and the optimization process S505 are made common as shown in FIG.
  • the CDFG file 14 after execution of the optimization process S505 is used as an input to perform the CDFG-C language conversion S53 and the CDFG-C ++ language conversion S56, thereby making it possible to further share the processing program. If the common part is increased in this way, there is a merit that the management of the program becomes easy.
  • CDFG file specifications are standardized, different vendors can create and interconnect each conversion process. This allows each vendor to focus on their areas of expertise and perform higher quality conversions.
  • processing such as video decoding
  • a process that executes a large amount of the same operation such as a DCT operation
  • a process that changes the contents of the process in a complicated manner depending on data such as variable-length code processing, is suitable for execution by software. ing.
  • the hardware description language source code which is the design data of the existing LSI
  • the hardware-oriented processing is converted into the verilog source code and converted into the LSI
  • the software-oriented processing is converted into the C language. Then, it can be executed by the CPU.
  • FIG. 25 is an example of the code conversion apparatus 1 in the present embodiment.
  • the process division processing unit 607 performs a process division process.
  • the process division process is a process of dividing the input CDFG 14 into a process for hardware and a process for software.
  • the verilog module may be mechanically classified based on the operation profile of the original LSI, or the CDFG 14 is displayed in the GUI as shown in FIG. It may be carved while considering. By dividing the processing in this way, CDFG 140 and CDFG 141 are generated.
  • FIG. 23 is a conversion flow from the source code described in the hardware description language to the source code described in the programming language in this embodiment.
  • the CDFG 140 includes software-oriented processing, and the CD source code 15 is generated using the substep information in the CDFG 140 by the CDFG-C language conversion S53.
  • the CDFG 141 includes hardware-oriented processing, and the CDFG-verilog conversion S57 generates the verilog source code 19 using the step information in the CDFG 141.
  • processing described in a single source code can be performed in a plurality of ways including hardware processing languages and programming languages. It becomes possible to perform load distribution by converting into language source code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

　ハードウェア記述言語は並列処理型の言語であり、処理の記述順序は重要ではないが、プログラミング言語は逐次処理型の言語であるため、処理の記述順序が大きな意味を持っている。このため、最終的にハードウェア記述言語で記述されたコードをプログラミング言語で記述されたコードに変換する際には、処理の依存関係に基づいてクロックサイクルよりも小さな単位で記述順序を決定する必要がある。　本発明ではクロックサイクルに相当するステップをさらに分割したサブステップと呼ぶ概念を導入する。データフロー上の各ノードは種類にかかわらず、常に１サブステップ使用するものとして、各ノードにサブステップ番号を割り当て、サブステップ番号の小さなものから順次、プログラミング言語のソースコードに変換していくことで、元の依存関係を維持した状態で各処理の記述順序を決定できるようになる。

Description

異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置
　本発明は、異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置に関する。
　本技術分野の背景技術として、特開２００７－００１２３４号公報（特許文献１）がある。該公報には、「動作合成装置１は、Ｃ＋＋、systemＣ等の高度記述言語で記述された動作合成対象に対する動作合成レベル記述１００ａと、同じ高度記述言語で記述された動作合成に対するデバッグ向けの動作合成レベル記述１００ｂから、デバッグ用信号抽出機能部１１がデバッグ信号を抽出して、抽出したデバッグ信号のトレース情報を信号トレース情報記録ＤＢ機能部１２がハードディスクに記録し、動作合成処理機能部１３が、デバッグ向け動作合成レベル記述１００ｂと該トレース情報に基づいて動作合成処理を行って、デバッグ向けＲＴＬ回路生成機能部１４が、該動作合成結果からＲＴＬを生成する」と記載され、特許文献１ではステップを用いたスケジューリングについて簡単に触れられている（要約等参照）。
特開２０１１－５９９０８
　ハードウェア記述言語は並列処理型の言語であり、プログラミング言語は逐次処理型の言語であるため、特許文献１に記載のようなステップを用いたスケジューリングは動作合成（プログラミング言語で記述されたソースコードからハードウェア記述言語で記述されたソースコードへの変換）には有効であるが、そのままでは動作合成の逆方向の変換（ハードウェア記述言語で記述されたソースコードからプログラミング言語で記述されたソースコードへの変換）に利用することはできなかった。
　上記目的を解決するために、例えば特許請求の範囲に記載の構成を採用する。
  本願は上記目的を解決する手段を複数含んでいるが、その一例を挙げるならば、複数の処理が実行される順序が複数の処理の記述順に影響されない第一のプログラム言語で記述された第一のソースコードから複数の処理が実行される順序が複数の処理の記述順に影響される第二のプログラム言語で記述された第二のソースコードに変換するコード変換方法において、第一のソースコードに基づきフィールド情報を作成するフィールド情報作成ステップと、フィールド情報作成ステップで作成されたフィールド情報に基づき第二のプログラム言語で記述された第二のソースコードを生成する生成ステップと、作成ステップで作成されたソースコードを出力する出力ステップと、を備え、フィールド情報は、第一のソースコードに含まれる複数のノード毎に、他のノードと入出力関係を示す入出力情報と、第一のソースコードの出力に対応したノードから第一のソースコードの入力に対応したノードに向かいノード毎に値が小さくなるサブステップ値と、を有し、生成ステップにおいて生成される第二のソースコードは、サブステップ値が小さいノードから順に入出力情報に示される関係を有するノードを有する。
　本発明を用いることで、ハードウェア記述言語で記述されたソースコードからプログラミング言語で記述されたソースコードへの変換を行う際に、元のソースコードにおける各処理の依存関係を崩すことなく、プログラミング言語で記述されたソースコードにおける処理の実行順序を決定することが可能となる。
ｖｅｒｉｌｏｇのソースからＣ言語のソースへの変換フロー例 変換対象の回路例 変換対象回路のｖｅｒｉｌｏｇ記述例 変換対象回路のｖｅｒｉｌｏｇ記述から呼び出されるヘッダーファイルの例 プリプロセッサ処理済みファイルの例 ＣＤＦＧの例 字句解析、構文解析の説明図 構文解析およびＣＤＦＧ生成の説明図 生成されたＣＤＦＧツリー群の例 ツリー結合処理のフローチャートの例 結合後のＣＤＦＧの例 スケジューリング処理の処理フローの例 ｓｃｈｅｄ＿ｎｏｄｅ関数の処理フローの例 暫定サブステップ割り当て例 サブステップ番号調整例 スケジューリング後のＣＤＦＧの例 スケジューリング後のＣＤＦＧの例 生成されたＣ言語のソースコードの例 生成されたＣ言語のソースから呼び出されるヘッダーファイルの例 コード生成処理の処理フローの例 第二の実施例におけるコード生成処理の処理フローの例 第三の実施例におけるコード生成処理の処理フローの例 第四の実施例におけるコード生成処理の処理フローの例 コード変換装置の構成の例 コード変換装置の構成の例
　近年、ＬＳＩの設計にはｖｅｒｉｌｏｇなどのハードウェア記述言語が広く使用されている。ハードウェア記述言語で回路を設計する際には、クロックサイクルやゲート遅延などを意識してソースコードを作成する必要があり、電気回路の知識が要求され、専門分野の異なる人には敷居が高かった。
　また、ＬＳＩの微細化などによって、ＬＳＩの搭載素子の影響や動作クロック周波数が変化した場合には、ソースコードの大幅な書き換えが必要であった。このような課題を解決するため、Ｃ言語のような一般的なプログラミング言語（以下、単にプログラミング言語と呼ぶ）で記述されたソースコードをハードウェア記述言語で記述されたソースコードに変換する、いわゆる、動作合成と呼ばれる技術が普及しつつある。
　動作合成では、変換対象のプログラミング言語のソースコードから、データフローを抽出し、これを変換先のハードウェア記述言語の動作クロック周期に相当するステップ（またはサイクル）と呼ばれる単位に区切っていくことによってスケジューリング処理を行う。ステップの長さはパラメータとして自由に設定できるため、クロック周波数などの変更に容易に追従することが可能である。
　動作合成を使用することでこのようなメリットを得ることができるが、動作合成を行うためには、目標とする機能をプログラミング言語で記述したソースコードが必要である。しかしながら、既存のＬＳＩのクロック周波数を変更するような場合では、目標とする機能は既にハードウェア記述言語で記載されており、プログラミング言語で記述したソースコードは存在しないことが多い。このような場合、動作合成とは逆方向の変換、すなわち、ハードウェア記述言語で記載されたソースコードをプログラミング言語で記述されたソースコードに変換するツールが存在すると便利である。
　ここで、ハードウェア記述言語は並列処理型の言語であり、各演算は同時に処理されるため、一部の例外を除き、処理の記述順序は結果に影響を与えない。例えばハードウェア記述言語の一つであるｖｅｒｉｌｏｇ言語で、信号ａに１０を代入する処理である「ａｓｓｉｇｎ　ａ＝１０；」と信号ｂに信号ａの値を代入する処理である「ａｓｓｉｇｎ　ｂ＝ａ；」の二つの文を記述する場合、どちらを先に記述しても、ａとｂの両方に１０が代入される。
　一方、プログラミング言語は逐次処理型の言語であるため、処理の記述順序が結果に大きな影響を与える。例えば、上記と同じ内容の処理をＣ言語で記述すると「ａ＝１０；」及び「ｂ＝ａ；」となる。
　ハードウェア記述言語とプログラミング言語で記述された二つの文をこの順序で記述すれば、変数ａと変数ｂの両方に１０が代入されることになるが、逆の順序で記述した場合には、１０を代入する前にａに格納されていた値（例えば１）がｂに代入されることになり、変数ａには１０、変数ｂには１が代入されることとなる。
　すなわち、最終的にハードウェア記述言語で記述されたソースコードをプログラミング言語で記述されたソースコードに変換する際には、各処理の依存関係に基づいて各処理を記述する順序を決定する必要がある。
　動作合成（プログラミング言語で記述されたソースコードからハードウェア記述言語で記述されたソースコードへの変換）では、データフローをレジスタによって複数のステップに分割してスケジューリング処理を行っている。
　特許文献１に記載されているステップを用いたスケジューリングは動作合成には有効であるが、同一ステップ内にある複数の処理に対する処理の順序付けを行っていないため（ハードウェア記述言語ではこの順序付けが不要なため）、そのままでは動作合成の逆方向の変換（ハードウェア記述言語で記述されたソースコードからプログラミング言語で記述されたソースコードへの変換）に利用することはできない。
　この問題を解決するために、本発明ではクロックサイクルに相当するステップをさらに分割したサブステップと呼ぶ仮想的な時間単位を導入する。データフロー上の各ノードは種類にかかわらず、処理を行うのに１サブステップ分の時間を使用するものとして、各ノードにサブステップ番号を割り当てる。その後、サブステップ番号の小さなノードから順次、プログラミング言語のソースコードに変換していくことで、元のソースコードにおける依存関係を維持した状態で各処理の記述順序を決定できるようになる。なお、サブステップ番号を便宜的に与えるものであるため、サブステップ番号を以下で説明するものと逆の順序で設定することにより、サブステップ番号の大きなノードから順次変換して目的のソースコードを得ることも可能である。
　以下、図面を用いて本実施例について説明する。
  図２４は、実施例１にかかるコード変換装置１の一例である。
  コード変換装置１は、プリプロセッサ処理部６００と、字句解析処理部６０１と、構文解析処理部６０２と、ツリー結合処理部６０３と、スケジューリング処理部６０４と、最適化処理部６０５と、コード生成処理部６０６と、ＣＰＵ６１０と、メモリ６１１と、記録部６１２と、入力部６１３と、出力部６１４とが、バス６１４を介して接続されて構成される。
　プリプロセッサ処理部６００と、軸解析処理部６０１と、構文解析処理部６０２と、ツリー結合処理部６０３と、スケジューリング処理部６０４と、最適化処理部６０５と、コード生成処理部６０６は、図２４に例示するようにハードウェアとしてコード変換装置１に搭載することができる。
　また、６００から６０６の各処理部は、記録部６１２に記録されたプリプロセッサプログラム６００、字句解析プログラム６０１と、構文解析プログラム６０２と、ツリー結合プログラム６０３と、スケジューリングプログラム６０４と、最適化プログラム６０５と、コード生成プログラム６０６をＣＰＵ６１０がメモリ６１１に展開し、展開した各プログラムをＣＰＵ６１０が実行することによって各処理部の機能を発揮するようにして、ソフトウェアとしてコード変換装置１に搭載しても良い。
　以下では、説明を簡略化するため、各処理部が主体となって各処理を行うこととして説明する。なお各処理部をソフトウェアで実現した場合にはその各種プログラムをＣＰＵ６１０が実行することで実現される各処理部を各処理の主体として説明する。
　プリプロセッサ処理部６００は、入力されたソースとヘッダーファイルからマクロの置換、コメントの除去などのプリプロセッサ処理を行う。
　字句解析処理部６０１は、プリプロセッサ処理済みファイルに字句解析処理を行い、トークンと呼ばれる単位に分割する。トークンとはこれ以上細かく分割すると、本来の意味を持たなくなる最小単位の文字列である。
　構文解析処理部６０２は、構文解析処理を行う。構文解析処理は、ｖｅｒｉｌｏｇソースコードの各行（または数行分の固まりであるブロック）に対応したトークン列から、部分的なＣＤＦＧ構造であるＣＤＦＧツリーを生成する処理である。
　ツリー結合処理部６０３は、ツリー結合処理を行う。ツリー結合処理は、複数個のＣＤＦＧツリーを一つのＣＤＦＧに結合する処理である。
　スケジューリング処理部６０４は、各処理の依存関係を保ったまま、各ノードを順次Ｃ言語のソースコードに変換するために各ノードの順序付け、すなわち、スケジューリング処理を行う。
　最適化処理部６０５は、作成されるＣ言語のソースコードの処理性能などを向上させるための最適化処理を行う。
　コード生成処理部６０６は、スケジューリングされたＣＤＦＧをサブステップ番号順に対応するＣ言語のソースコードに置き換えていくコード生成処理を行う。
　図１は、本実施例におけるハードウェア記述言語で記述されたソースコードからプログラミング言語で記述されたソースコードへの変換フローである。本フローチャートにおいて例えばステップ５０１をＳ５０１というように表現する。
  本実施例では、ハードウェア記述言語としてｖｅｒｉｌｏｇをプログラミング言語としてＣ言語を例に説明するが、本発明はこの組み合わせに限定されるものではなく、並列処理型の記述言語から、逐次処理型の記述言語への変換に一般的に用いることができる。
　図２は、本実施例で変換対象となる回路である。変換対象の回路２０は乗算器２１、加算器２２、２５、フリップフロップ２３、２４で構成されている。フリップフロップ２３、２４はクロック信号ｃｌｋの立ち上がりエッジで動作し、非同期リセット信号ｒｓｔ＿ｎをＬｏｗレベルに設定すると出力が０にリセットされる。この回路２０は、フリップフロップ２３、２４によって二つのパイプラインステージに分割されている。フリップフロップ２３、２４よりも左側がステージ０、右側がステージ１となる。ステージは動作合成の分野ではステップという言葉で表現されることもある。
　図３に、この回路をｖｅｒｉｌｏｇで記述した例を示す。この図において、左側の数字は行番号であり、ソースコードには含まれない。本リストはｖｅｒｉｌｏｇに準拠しているため、各部の詳細説明は省略することとする。
　図４に、図３の２行目のｉｎｃｌｕｄｅ文で読み込まれるヘッダーファイルを示す。ヘッダーフェイルにはマクロの定義等が記載されている。
  このｖｅｒｉｌｏｇソースコード１０とヘッダーファイル１１が本実施例における変換処理の対象となる。なお、本実施例では、ソースコード１０とヘッダーファイル１１はどちらも単一のファイルで実現しているが、複数のファイルで構成しても良いし、ヘッダーファイル１１は存在しなくても構わない。
　［プリプロセッサ処理Ｓ５００］
  図１中のプリプロセッサ処理Ｓ５００において、プリプロセッサ処理部６００はｖｅｒｉｌｏｇソースコード１０とヘッダーファイル１１を読み込み、マクロの置換、コメントの除去などの処理を行う。プリプロセッサ処理Ｓ５００の出力であるプリプロセッサ処理済みファイル１２の例を図５に示す。
　このプリプロセッサ処理済みファイル１２に対して、字句解析Ｓ５０１、構文解析Ｓ５０２、ツリー結合Ｓ５０３が行われることで、元のソースコードで実行される処理に対応したデータフローと制御フローを一つにまとめた中間形式であるＣＤＦＧ（Ｃｏｎｔｒｏｌ　Ｄａｔａ　Ｆｌｏｗ　Ｇｒａｐｈ）が生成される。
　［ＣＤＦＧの構造］
  図６に、ＣＤＦＧの構造の一例を示す。
  図６（ａ）は、この例における変換対象のｖｅｒｉｌｏｇソースコードであり、図５の３２行目のａｓｓｉｇｎ文に相当する。このｖｅｒｉｌｏｇソースコードによれば、信号ａ［１５：０］とｂ［１５：０］の乗算を行った後に、乗算の結果得られた値に信号ｘ［１５：０］を加算することが示されている。
　図６（ｂ）は、図６（ａ）のｖｅｒｉｌｏｇソースコードをＣＤＦＧに変換したものである。ＣＤＦＧにおいて、実行されるそれぞれの処理はノードで表わされ、各ノードは向きを持った矢印で接続されて図６（ｂ）のようにグラフ構造となる。
　図６（ｃ）は、ＣＤＦＧ構造体フィールド情報の例である。ＣＤＦＧ構造体フィールド情報には、各ノードごとの属性情報４０が格納されている。属性情報４０はＩＤ番号４１、ノードタイプ４２、信号名４３、バス情報４４、入力４５～４７、ｓｔ４８、ｓｓｔ４９から構成される。
　ＣＤＦＧはどのような方法で実装しても良いが、ここではリンク構造を持ったＣ言語の構造体の集合として実装している。
　図６（ｂ）において、信号ａ［１５：０］、ｂ［１５：０］、ｘ［１５：０］はそれぞれノード３０、３１、３２に対応している。また、これらのノードには図６（ｃ）に示すように、ＩＤ番号４１が「１」、「２」、「３」のように割り振られており、ノードタイプ４２は信号名等の識別子であることを示す「ＩＤ」となっている。
　図６（ａ）のｖｅｒｉｌｏｇソース中の乗算はノード３３に対応しており、加算はノード３４に対応している。そして、ノード３３、３４のＩＤ番号４１はそれぞれ「４」、「５」とされ、タイプ４２は、それぞれ乗算であることを示す「ＭＵＬＴ」、加算であることを示す「ＡＤＤ」と格納される。
　ここで、まず信号ａ［１５：０］とｂ［１５：０］に対して乗算を実行するため、ノード３３の入力０、１にそれぞれ信号ａ［１５：０］とｂ［１５：０］を示すＩＤ番号「１」と「２」がリンク情報として格納される。
　同様にノード３４はノード３３の出力とノード３２の出力に対して加算を行うため、入力０、１にそれぞれノード３３、ノード３２を示すＩＤ番号「４」と「３」がリンク情報として格納される。ノード３４の出力信号名であるｓは、図６（ａ）のｖｅｒｉｌｏｇソースコードで指定されている。
　なおこの表中のｓｔ４８、ｓｓｔ４９はそれぞれステップ、サブステップを意味している。ステップは図２におけるパイプラインステージに相当する概念である。サブステップは、ステップをさらに細分化した単位であり、詳細については後述する。サブステップの値はスケジューリング処理Ｓ５０４で決定するものであり、それ以前の時点では確定していないため、図６（ｃ）では「－」で記載されている。
  この様にＣＤＦＧを使うとデータフロー及び制御フローを表現することが可能となる。
　［字句解析処理Ｓ５０１］
  次に図１のＳ５０１～Ｓ５０３のＣＤＦＧの生成手順を説明する。
  図７は、字句解析、構文解析の説明図である。
  図８は、構文解析及びＣＤＦＧ生成の説明図である。
  プリプロセッサ処理済みファイル１２は、字句解析処理部６０１による字句解析処理５０１でトークンと呼ばれる単位に分割される。字句解析処理Ｓ５０１を行うためのツールとしてはｌｅｘが有名であり、本実施例中の字句解析処理Ｓ５０１もｌｅｘを使って実現することが可能である。その使用方法については様々な文献に記載されているため、ここでは説明を省略する。また、ｌｅｘ以外のツールを使用することも可能であり、本発明はｌｅｘを使用した場合に限定されるものではない。
　［構文解析処理Ｓ５０２］
  次に、字句解析処理５０１で得られたトークン列に対して構文解析処理部６０２が構文解析処理Ｓ５０２を行う。本実施例では、構文解析ツールとして有名なｙａｃｃを使用する場合を想定しているが、上記と同様にｙａｃｃ以外のツールを使用することも可能であり、本発明はこれに限定されるものではない。
　ｙａｃｃを使用する場合には、あらかじめ処理対象とする言語の構文をパターン情報として用意しておき、トークン列に対して順次パターンマッチングを行い、マッチした場合にはあらかじめ定義しておいたルールに対応する処理を行うという形式になる。
　図７の構文解析Ｓ５０２の例では、与えられたトークン列を左から順次走査しながらマッチングをしており、トークン列ｓ［１５：０］が最初にマッチしている（マッチング５０）。このパターンが出現した場合にはノードタイプがＩＤのノードを生成する様にルールを指定しておくと、図８のマッチング５０にあるようにノードｓが生成される。同様にマッチング５１、５２でノードａとノードｂが生成される。マッチング５３では乗算ノードが生成され、ノードａ、ｂと接続される。マッチング５４ではノードｘが生成され、次のマッチング５５では、加算ノードが生成され、乗算ノードとノードｘに接続される。最後にマッチング５６で左辺のノードと右辺のノードを結合することで、この行に対応したＣＤＦＧツリーが完成する。
　図９は、図５の他の行に対しても同様に字句解析処理Ｓ５０１と構文解析処理Ｓ５０２を順次実施することによって生成される、複数個のＣＤＦＧツリーの例である。
　図５の９～１５行目の入出力ポート定義は図９（ａ）の入出力ノードに変換される。今回の例では入力信号のノードタイプ４２は「ＩＮ」、出力信号のノードタイプ４２は「ＯＵＴ」となる。双方向の入出力ポートはノードタイプ４２が「ＩＮ」および「ＯＵＴ」の２つのポートに分けて記述する。
　図５の２１～３０行目のフリップフロップ記述は図９（ｂ）の様に変換される。この図の様にフリップフロップは入力側と出力側の２つのノードで表現し、それぞれのノードタイプ４２は「ＦＦ０」、「ＦＦ１」となる。「ＦＦ０」の値はクロックの立ち上がりで「ＦＦ１」に転送されることになる。
　図５の３２～３４行目の組み合わせ回路は図９（ｃ）の様に変換される。
　［ツリー結合処理Ｓ５０３］
  ツリー結合処理部６０３は、ツリー結合処理Ｓ５０３を行う。ただし、必ずしも全てのノードが一つのＣＤＦＧに統合されるわけではない。この処理は、図９の各ＣＤＦＧツリー中のノードタイプがＩＤであるノードを削除し、本来のリンク先につなぎ替える処理となる。
　図１０は、ツリー結合処理のフローチャートの一例である。本フローチャートにおいて例えばステップ７０１をＳ７０１というように表現する。
  まず、各ノードのＩＤ番号を指定するための変数ｉを０に初期化する（Ｓ７０２）。次にノードのＩＤ番号がｉに等しいノードｉを探して、そのノード情報を読み込む（Ｓ７０３）。次に読み込んだノードｉのノードタイプがＩＤであるかどうかの調査を行う（Ｓ７０４）。ＩＤでない場合はつなぎ替えが不要なので、ｉに１を加算して、本ノードの処理は終了する（Ｓ７１３）。まだ調査していないノードが残っていれば、次のノードの調査を実施する（Ｓ７１４）。
　一方、調査Ｓ７０４でノードタイプがＩＤであった場合は、本来のリンク先の探索を行う。まず、リンク先のノードのＩＤ番号を指定するための変数ｊを０に初期化する（Ｓ７０５）。次にノードのＩＤ番号がｊに等しいノードｊを探して、そのノード情報を読み込む（Ｓ７０６）。
　次に読み込んだノードｊのタイプがＩＤ、ＯＵＴ、ＦＦ０であるかどうかの調査を行う（Ｓ７０７）。ＩＤ、ＯＵＴ、ＦＦ０の場合にはそのノードは本来のリンク先になり得ないので、ｊに１を加算して、本ノードの処理は終了する（Ｓ７０９）。まだ調査していないノードが残っていれば、次のノードの調査を実施する（Ｓ７１０）。
　ノードｊのタイプがＩＤ、ＯＵＴ、ＦＦ０で無い場合は、ノードｉとノードｊの信号名を比較する（Ｓ７０８）。両者が等しい場合は、ノードｊが本来のリンク先であるため、全てのノードを走査して、リンク先がノードｉとなっているリンクのリンク先を全てのノードｊに変更する（Ｓ７１１）。その後、ノードｉを削除することで、ノードのリンク先変更処理が完了する。Ｓ７０８について、信号名が一致していない場合は、Ｓ７０９からＳ７１０の処理を行う。
　これらを全てのノードｉに対して実行すると、ツリー結合処理Ｓ５０３が完了する。
　図１１は、図９の全てのノードに対してツリー結合処理Ｓ５０３を行った結果である。
  このようにして結合されたＣＤＦＧの各ノードをＣ言語の文法に則したソースコードで記述することによって、最終結果である処理全体のＣ言語のソースコードを作成することができる。
　［スケジューリング処理Ｓ５０４］
  ここで重要になるのが、各ノードをＣ言語のソースコードに記述していく順番である。Ｃ言語のような逐次実行型の言語では、ｖｅｒｉｌｏｇのような並列実行型の言語と異なり、処理の記述順が重要な意味を持つ。このため、各処理の依存関係を保ったまま、各ノードを順次Ｃ言語のソースコードに変換する必要がある。これを実現するためにスケジューリング処理部６０４は各ノードの順序付け、すなわち、スケジューリング処理Ｓ５０４を行う。
　ここで言うスケジューリングは動作合成等で用いられるステップのようなクロックサイクル単位のスケジューリングよりもさらに細かい単位のスケジューリングであり、これを実現するために、ここでサブステップという仮想時間単位を導入する。なお、以下の説明ではステップをｓｔ、サブステップをｓｓｔと省略することもある。この考え方では、各ノードはノードタイプにかかわらず、処理の実行に１サブステップ分の時間を使用するものと仮定してスケジューリングを行う。
　図１２は、スケジューリング処理Ｓ５０４の全体フローの一例である。
  図１３は、図１２のフロー中のＳ７２５から再帰的に呼び出す関数ｓｃｈｅｄ＿ｎｏｄｅの処理フローの一例である。
　　スケジューリング処理Ｓ５０４は、各ノードに暫定的なサブステップ番号を設定する前半処理と、暫定的なサブステップ番号を調整して最終的なサブステップ番号を決定する後半処理に分けることができる。
　最初に、前半の暫定サブステップ番号の設定処理について説明する。この処理の概要は以下の通りである。
　１．出力ノード（ＯＵＴ）、ＦＦの入力ノード（ＦＦ０）に対して、サブステップ番号０を設定する。
　２．各出力ノードまたはＦＦの入力ノードを起点として、その入力ノードに対して、現在のノードのサブステップ番号から定数Ｎを減算した値を設定する（Ｎは正の定数であれば何でも良い。今回はＮ＝１としている）。ただし、そのノードに既に別のサブステップ番号が設定されており、その値が新しく設定しようとしているサブステップ番号よりも小さい場合は、以前の設定値をそのままサブステップ番号として使用する。
　３．順次入力側へノードをたどりながら２の処理を再帰的に実行する。
　図１２のスケジューリング処理Ｓ５０４の前半部分（Ｓ７２２～Ｓ７２７）が上記の「１．」の処理に該当し、そこから「２．」の処理として図１３の関数ｓｃｈｅｄ＿ｎｏｄｅを再帰的に呼び出して実行する。関数呼び出し時には引数の一つとして、対象とするノードに設定するサブステップ番号を指定する。なお、図１３の例は、各ノードの入力数は最大で３個である場合を想定しているが、本発明はこれに限定されるものではない。
　図１４は、上記の手順で図１１のＣＤＦＧの各ノードに対して暫定的なサブステップ番号を設定した様子の一例である。図中において五角形で囲まれた数字が各ノードのサブステップ番号である。「０」から順次１を減算しながらサブステップ番号を設定しているため、サブステップ番号は「０」以下の数となっている。またノード４０のサブステップ番号はノード４３からたどった場合は「－１」、ノード４２または４４からたどった場合は「－２」となるが、関数ｓｃｈｅｄ＿ｎｏｄｅ　中のＳ７３２～Ｓ７３４の処理によって最終的に、一番小さい値である「－２」が設定されている。
　スケジューリング処理５０４の後半の最初に行うＳ７６０とＳ７６１は全てのサブステップ番号を「０」以上の値にするための処理である。Ｓ７６０は全てのサブステップ番号の中で一番小さい値（ｓｓｔ＿ｍｉｎ）を探す処理である。図１４の例では「－３」が一番小さいのでｓｓｔ＿ｍｉｎ＝－３となる。次のＳ７６１では、全てのノードに対してサブステップ番号の値からｓｓｔ＿ｍｉｎの値を減算する。
　図１５は、上記の処理を図１４のＣＤＦＧに行った結果の例である。ここでＳ７６２を行い、入力ノードとＦＦの出力ノード（ＦＦ１）のサブステップ番号を０に設定する。この処理は必須ではないが、入力やフリップフロップ更新のタイミングを揃えることで、図示したＣＤＦＧや生成するＣ言語のソースコードが見やすくなるといったメリットがある。
　図１６は、Ｓ７６２を行った後のＣＤＦＧを、同じサブステップ番号が同じ列に並ぶように配置し、ステップ番号が同じノードをグループ分けして書き直したＣＤＦＧの例である。これがスケジューリング処理Ｓ５０４が完了した状態におけるＣＤＦＧとなる。
　このようにスケジューリング後のＣＤＦＧでは、各ノードはステップ番号とサブステップ番号を持つことになる。図６に対応する部分のスケジューリング後のＣＤＦＧ構造体のフィールド情報を図１７に示す。図６（ｃ）と比較すると、ｓｓｔの値が格納されていることおよび、ツリー結合処理によって先頭の３つのノードが結合後のノードに置き換わっていることがわかる。この様にＣＤＦＧ中にステップ番号とサブステップ番号を保持しているため、ここからステップ番号を用いてハードウェア記述言語のソースコードを生成することや、サブステップ番号を用いてプログラミング言語のソースコードを生成することが可能であり、ＣＤＦＧに言語変換のハブの役割を持たせることができる。
　［最適化処理Ｓ５０５］
  最適化処理Ｓ５０５は、作成されるＣ言語のソースコードの処理性能などを向上させるために最適化処理部６０５が行う処理であり、実行結果に影響を与えない範囲での、処理順序の入れ替え（外側ループと内側ループの入れ替えなど）や処理の置き換え（割り算をシフトで代用）等を行うことができる。最適化処理Ｓ５０５について特に必要が無ければ実行しなくてもよい。。
　［コード生成処理Ｓ５０６］
  コード生成処理部６０６が行うコード生成処理Ｓ５０６は、スケジューリングされたＣＤＦＧをサブステップ番号順に対応するＣ言語のソースコードに置き換えていく処理である。図１６のＣＤＦＧをＣ言語のソースコードに変換した例を図１８に、Ｃ言語のソースコードから参照しているヘッダーファイルの例を図１９に示す。
　コード生成処理Ｓ５０６の処理フローを図２０を用いて説明する。ここでは説明が煩雑になるのを防ぐため、閉じ括弧の様に細かな要素に関する処理については説明を省略している部分もある。
　Ｃ言語のソースコードを生成する際には、まず、ヘッダー情報と関数名を出力する（Ｓ７８１）。図１８の１～４行目がこの処理で出力されたものである。ヘッダー情報には、コメントや必要なヘッダーファイルの読み込み命令等が含まれる。
　次に入出力信号定義を出力する。図１８の５～１０行目の関数の引数記述に対応する。なお出力信号については、ポインタ変数とすることで関数の呼び出し側に結果の値を返せるようにしている。
　次に内部信号の定義（Ｓ７８３）、フリップフロップの定義（Ｓ７８４）を行う。フリップフロップについては、関数の実行終了後にも値を保持し続けられるようにｓｔａｔｉｃ変数を用い、リセット時の値を初期値として代入しておく。
　最後に関数の本体を、サブステップ番号順に出力していく。まず、変数ｓｓｔを０に設定し（Ｓ７８５）、サブステップ番号が変数ｓｓｔの値と等しいノードを順次Ｃ言語の文法規則に従って出力する（Ｓ７８６）。例えば、図１６のノード３３は図１８の２５行目の様に出力される。ノード３３は信号名が定義されていないため、自動生成された内部信号名ｔ＿００００が左辺の値として使用されている。　また、フリップフロップは入力側と出力側の信号名にそれぞれ＿０と＿１を付けた変数を用意することで両者を区別し、実行に先立ってサブステップ番号０で、出力側の変数を入力側の変数に代入することで、クロックエッジでデータが転送されるというフリップフロップとしての動作を実現している。
　サブステップ番号が変数ｓｓｔの値と等しいノードが出力されると、変数ｓｓｔに１を追加し（Ｓ７８７）、全てのノードを走査したかを判定する（Ｓ７８８）。全てのノードを走査していない場合（Ｓ７８７のＮＯ）はＳ７８６に戻り、全てのノードを走査している場合（Ｓ７８７のＹＥＳ）はコード生成処理Ｓ５０６を終了する（Ｓ７８９）。
　プログラム言語では変数のビット幅は８、１６、３２のように離散的な値のみサポートしている場合が多いが、ハードウェア言語では任意のビット幅をサポートしている場合が多い。この差異については図１９で示すようなマクロを用意して対応することが可能である。
　このようにして生成されたＣ言語の関数をｍａｉｎ関数からクロック毎に実際の入力信号値に相当する値を関数の引数に設定して呼び出すことで、元のｖｅｒｉｌｏｇで記述された回路と同じ結果を得ることができるようになる。
　実施例１では、ｖｅｒｉｌｏｇからＣ言語への変換を一括して行っていたが、ＣＤＦＧの内容を中間結果としてファイルに出力して、処理を分割するとより柔軟性を高めることが可能となる。これを図２１を用いて説明する。
　この図において、ｖｅｒｉｌｏｇ－ＣＤＦＧ変換Ｓ５０とＣＤＦＧ－Ｃ言語変換Ｓ５２は実施例１と同じ処理である。ここで中間形式データを出力したファイル１３を経由することで、様々な言語間の相互変換を行うことが可能となる。
　ハードウェア記述言語としてはｖｅｒｉｌｏｇの他にＶＨＤＬが広く使用されているが、この変換フローに、ＶＨＤＬ－ＣＤＦＧ変換Ｓ５１を追加することで、ＶＨＤＬからＣ言語への変換も可能となる。ＶＨＤＬ－ＣＤＦＧ変換Ｓ５１とｖｅｒｉｌｏｇ－ＣＤＦＧ変換Ｓ５０は細かな相違点はあるが基本的な構造は同じであるため、内部の詳細説明は省略する。
　この場合、ＣＤＦＧ－Ｃ言語変換Ｓ５２をｖｅｒｉｌｏｇからの変換とＶＨＤＬからの変換で共通化できれば、変換ツールの開発工数などの面で有利となる。
　また、変換先のプログラミング言語をＣ＋＋言語などのＣ言語以外の言語としたい場合には、ＣＤＦＧ－Ｃ＋＋言語変換Ｓ５５を追加するだけでよく、前半のハードウェア記述言語からＣＤＦＧへの変換処理に関してはそのまま流用することも可能となる。ＣＤＦＧ－Ｃ＋＋言語変換Ｓ５５とＣＤＦＧ－Ｃ言語変換Ｓ５２の基本的な構造は同じであるため、内部の詳細説明は省略する。
　実施例２では、スケジューリング処理Ｓ５０４や最適化処理Ｓ５０５については、Ｃ言語出力用とＣ＋＋言語出力用に個別に用意していたが、図２２の様にスケジューリング処理Ｓ５０４や最適化処理Ｓ５０５を共通化し、最適化処理Ｓ５０５実行後のＣＤＦＧファイル１４を入力としてＣＤＦＧ－Ｃ言語変換Ｓ５３やＣＤＦＧ－Ｃ＋＋言語変換Ｓ５６を行うことによって、処理プログラムのさらなる共通化を行うことが可能となる。このように共通部分を増やすと、プログラムの管理が容易になるというメリットが生じる。
　また、ＣＤＦＧファイルの仕様が標準化されば、それぞれの変換処理を異なるベンダーが作成し、相互接続することも可能になる。これにより、各ベンダーは得意な分野に注力でき、より高品質な変換を行えるようになる。
　動画のデコードの様な処理では、ハードウェアで実行した方が効率の良い部分とソフトウェアで実行した方が効率の良い部分が混在している。例えばＤＣＴ演算の様に同じ演算を大量に実行する処理はハードウェアによる実行が適しており、可変長符号処理のようにデータによって処理の内容が複雑に変化するような処理はソフトウェアによる実行が適している。
　このような場合、既存のＬＳＩの設計データであるハードウェア記述言語のソースコードを分割して、ハードウェア向きの処理はｖｅｒｉｌｏｇソースコードに変換してＬＳＩ化し、ソフトウェア向きの処理はＣ言語に変換してＣＰＵで実行するといったことが可能となる。このように処理の負荷分散を適切に行うことで、コストや電力などで優れたシステムを構築することが可能となる。
　図２５は、本実施例におけるコード変換装置１の一例である。
  図２５において、図２４と重複するブロックは図２４のものと同様なため、説明を省略する。
  処理分割処理部６０７は、処理分割処理を行う。処理分割処理は入力されたＣＤＦＧ１４をハードウェア向きの処理とソフトウェア向きの処理に分割する処理である。分割の方法は、元のＬＳＩの動作プロファイルなどからｖｅｒｉｌｏｇのモジュールを機械的に分類しても良いし、ＣＤＦＧ１４を図１６のような形式でＧＵＩ表示して、人間がこれを見てデータフローを考慮しながら切り分けても良い。このようにして処理を分割することでＣＤＦＧ１４０とＣＤＦＧ１４１が生成される。
　図２３本実施例におけるハードウェア記述言語で記述されたソースコードからプログラミング言語で記述されたソースコードへの変換フローである。
　ＣＤＦＧ１４０にはソフトウェア向きの処理が含まれており、ＣＤＦＧ－Ｃ言語変換Ｓ５３によってＣＤＦＧ１４０中のサブステップ情報を用いてＣ言語のソースコード１５を生成する。
　一方、ＣＤＦＧ１４１にはハードウェア向きの処理が含まれており、ＣＤＦＧ－ｖｅｒｉｌｏｇ変換Ｓ５７によってＣＤＦＧ１４１中のステップ情報を用いてｖｅｒｉｌｏｇのソースコード１９を生成する。
　このように、ＣＤＦＧ中にステップ番号とサブステップ番号という２種類のスケジューリング情報を保持しておくことで、単一のソースコードに記述された処理を、ハードウェア処理言語やプログラミング言語を含む複数の言語のソースコードに変換して、負荷分散を行うことが可能となる。
１０：ｖｅｒｉｌｏｇで記載されたソースコード、１１：ｖｅｒｉｌｏｇで記載されたソースコード用ヘッダーファイル、１２：プリプロセッサ処理済みファイル、１３：中間形式のファイル、１４：中間形式のファイル、１５：Ｃ言語で記載されたソースコード、１６：Ｃ言語で記載されたソースコード用のヘッダーファイル、Ｓ５０：ｖｅｒｉｌｏｇ－ＣＤＦＧ変換、Ｓ５１：ＶＨＤＬ－ＣＤＦＧ変換、Ｓ５２～５３：ＣＤＦＧ－Ｃ言語変換、Ｓ５５～５６：ＣＤＦＧ－Ｃ＋＋言語変換、Ｓ５７：ＣＤＦＧ－ｖｅｒｉｌｏｇ変換、Ｓ５００：プリプロセッサ処理、Ｓ５０１：字句解析処理、Ｓ５０２：構文解析処理、Ｓ５０３：ツリー結合処理、Ｓ５０４：スケジューリング処理、Ｓ５０５：最適化処理、Ｓ５０６：コード生成処理

Claims (9)

  1. 　複数の処理が実行される順序が前記複数の処理の記述順に影響されない第一のプログラム言語で記述された第一のソースコードから複数の処理が実行される順序が前記複数の処理の記述順に影響される第二のプログラム言語で記述された第二のソースコードに変換するコード変換方法であって、
    　前記第一のソースコードに基づきフィールド情報を作成するフィールド情報作成ステップと、
    　前記フィールド情報作成ステップで作成されたフィールド情報に基づき前記第二のプログラム言語で記述された前記第二のソースコードを生成する生成ステップと、
    　前記作成ステップで作成されたソースコードを出力する出力ステップと、を備え、
    　前記フィールド情報は、前記第一のソースコードに含まれる複数のノード毎に、他のノードと入出力関係を示す入出力情報と、前記第一のソースコードの出力に対応したノードから前記第一のソースコードの入力に対応したノードに向かいノード毎に値が小さくなるサブステップ値と、を有し、
    　前記生成ステップにおいて生成される前記第二のソースコードは、前記サブステップ値が小さいノードから順に前記入出力情報に示される関係を有するノードを有することを特徴とするコード変換方法。
  2. 　複数の処理が実行される順序が前記複数の処理の記述順に影響されない第一のプログラム言語で記述された第一のソースコードからノードを取得し、前記第一のソースコードに基づき、前記第一のソースコードの処理毎にノードの入力と出力との関係を示す入出力情報をフィールド情報に格納する構文解析ステップと、
    　前記フィールド情報に記載された入出力関係にあるノード群同士を関連付けて前記フィールド情報に格納するツリー結合ステップと、
    　前記フィールド情報に基づき、前記第一のソースコードの出力に対応した出力ノードから前記第一のソースコードの入力に対応した入力ノードに向かいノード毎に値が小さくなるサブステップ値を各ノードの前記フィールド情報に格納するスケジューリングステップと、
    　前記サブステップ値が小さいノードから順に前記入出力情報を用いて、複数の処理が実行される順序が前記複数の処理の記述順に影響される第二のプログラム言語で記述された第二のソースコードを生成するコードステップと、
    　生成した第二のソースコードを出力する出力ステップと、
    　を備えることを特徴としたコード変換方法。
  3. 　前記サブステップ値は、前記第一のソースコードの出力に対応したノードから前記第一のソースコードの入力に対応したノードに向かい１ずつ小さくなることを特徴とした請求項１または２記載のコード変換方法。
  4. 　前記フィールド情報は、各ノードで行う処理の種類を備えることを特徴とした請求項１から３のいずれか記載のコード変換方法。
  5. 　前記フィールド情報は、前記第一のソースコードにおいて各処理が属するパイプラインステージのステージ番号を、当該処理に対応するノードのステップ値として保持するためのフィールドを備えることを特徴とした請求項１から４のいずれか記載のコード変換方法。
  6. 　前記フィールド情報は１ないし２以上のファイルに格納されていることを特徴とする請求項１から５のいずれか記載のコード変換方法。
  7. 　前記フィールド情報は、前記第一のソースコード中にフリップフロップの記述が含まれる場合には、当該フリップフロップに対応する入力用のノードと出力用のノードを生成することを特徴とした請求項１から６のいずれか記載のコード変換方法。
  8. 　複数の処理が実行される順序が前記複数の処理の記述順に影響されない第一のプログラム言語で記述された第一のソースコードから複数の処理が実行される順序が前記複数の処理の記述順に影響される第二のプログラム言語で記述された第二のソースコードに変換するコード変換装置であって、
    　前記第一のソースコードに基づきフィールド情報を作成するフィールド情報作成部と、
    　前記フィールド情報作成部で作成されたフィールド情報に基づき前記第二のプログラム言語で記述された前記第二のソースコードを生成する生成部と、
    　前記作成ステップで作成されたソースコードを出力する出力部と、を備え、
    　前記フィールド情報は、前記第一のソースコードに含まれる複数のノード毎に、他のノードと入出力関係を示す入出力情報と、前記第一のソースコードの出力に対応したノードから前記第一のソースコードの入力に対応したノードに向かいノード毎に値が小さくなるサブステップ値と、を有し、
    　前記生成部において生成される前記第二のソースコードは、前記サブステップ値が小さいノードから順に前記入出力情報に示される関係を有するノードを有することを特徴とするコード変換装置。
  9. 　複数の処理が実行される順序が前記複数の処理の記述順に影響されない第一のプログラム言語で記述された第一のソースコードから複数の処理が実行される順序が前記複数の処理の記述順に影響される第二のプログラム言語で記述された第二のソースコードに変換するプログラムであって、前記プログラムはコンピュータに、
    　前記第一のソースコードに基づきフィールド情報を作成するフィールド情報作成機能と、
    　前記フィールド情報作成ステップで作成されたフィールド情報に基づき前記第二のプログラム言語で記述された前記第二のソースコードを生成する生成機能と、
    　前記作成ステップで作成されたソースコードを出力する出力機能と、を実現させ、
    　前記フィールド情報は、前記第一のソースコードに含まれる複数のノード毎に、他のノードと入出力関係を示す入出力情報と、前記第一のソースコードの出力に対応したノードから前記第一のソースコードの入力に対応したノードに向かいノード毎に値が小さくなるサブステップ値と、を有し、
    　前記生成機能において生成される前記第二のソースコードは、前記サブステップ値が小さいノードから順に前記入出力情報に示される関係を有するノードを有することを特徴とするプログラム。
PCT/JP2013/057345 2013-03-15 2013-03-15 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置 WO2014141457A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/057345 WO2014141457A1 (ja) 2013-03-15 2013-03-15 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/057345 WO2014141457A1 (ja) 2013-03-15 2013-03-15 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置

Publications (1)

Publication Number Publication Date
WO2014141457A1 true WO2014141457A1 (ja) 2014-09-18

Family

ID=51536152

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/057345 WO2014141457A1 (ja) 2013-03-15 2013-03-15 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置

Country Status (1)

Country Link
WO (1) WO2014141457A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112166409A (zh) * 2018-06-06 2021-01-01 欧姆龙株式会社 控制系统、控制系统的控制方法以及控制系统的程序

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0950448A (ja) * 1995-08-08 1997-02-18 Hitachi Ltd 論理装置の検証方法
JP2002183234A (ja) * 2000-12-15 2002-06-28 Sharp Corp デジタル回路の共同シミュレーション方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0950448A (ja) * 1995-08-08 1997-02-18 Hitachi Ltd 論理装置の検証方法
JP2002183234A (ja) * 2000-12-15 2002-06-28 Sharp Corp デジタル回路の共同シミュレーション方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TAKESHI MATSUMOTO ET AL.: "An Approach to Equivalence Checking by Symbolic Simulation between Behavioral and RTL Designs", IEICE TECHNICAL REPORT, vol. 106, no. 32, 5 May 2006 (2006-05-05), pages 7 - 12 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112166409A (zh) * 2018-06-06 2021-01-01 欧姆龙株式会社 控制系统、控制系统的控制方法以及控制系统的程序
CN112166409B (zh) * 2018-06-06 2023-11-14 欧姆龙株式会社 控制系统、控制系统的控制方法以及记录介质

Similar Documents

Publication Publication Date Title
US8286108B2 (en) System and method for synthesis reuse
Takamaeda-Yamazaki Pyverilog: A python-based hardware design processing toolkit for verilog hdl
US9075624B2 (en) Compilation of system designs
US9244810B2 (en) Debugger graphical user interface system, method, and computer program product
CN105814568A (zh) 逻辑电路生成装置以及方法
JP2011512602A (ja) 同期から非同期への論理変換
US8701059B2 (en) Method and system for repartitioning a hierarchical circuit design
US10606972B2 (en) Method, design program, and design apparatus of a high level synthesis process of a circuit
CN113569524A (zh) 芯片设计中基于综合网表提取时钟树的方法及应用
WO2015075805A1 (ja) ソースコード分割方法及びｌｓｉ実装装置
US6964027B2 (en) System and method for optimizing exceptions
Manoranjan et al. Qualifying relative timing constraints for asynchronous circuits
WO2000072185A2 (en) Behavioral-synthesis electronic design automation tool and business-to-business application service provider
CN118708175B (zh) 参数配置方法、装置、设备、存储介质及程序产品
WO2014141457A1 (ja) 異なる言語間のコード変換方法、コード変換プログラムおよびコード変換装置
JP2004303022A (ja) プリプロセッサ、集積回路の設計システム及び集積回路の設計方法
US9600613B1 (en) Block-level code coverage in simulation of circuit designs
CN116384297A (zh) 一种芯片时钟约束文件的生成方法
Khilko et al. Desynchronization of a synchronous circuit to synthesize self-timed circuit
US8667434B1 (en) System, method, and computer program product for altering a hardware description based on an instruction file
JP2010257003A (ja) 論理等価性検証システム、論理等価性検証方法、半導体集積回路の製造方法、制御プログラムおよび可読記憶媒体
Mao et al. Automated mapping of asynchronous circuits on fpga under timing constraints
Doboli et al. The definition of a VHDL-AMS subset for behavioral synthesis of analog systems
JP4702357B2 (ja) 動作レベル記述とレジスタ転送レベル記述間の等価性検証方法及び装置並びにプログラム
Wei et al. ECO timing optimization with negotiation-based re-routing and logic re-structuring using spare cells

Legal Events

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

Ref document number: 13878156

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: 13878156

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP