WO2010058981A2 - Procédé et système pour convertir un code en langage de haut niveau en code hdl - Google Patents

Procédé et système pour convertir un code en langage de haut niveau en code hdl Download PDF

Info

Publication number
WO2010058981A2
WO2010058981A2 PCT/KR2009/006833 KR2009006833W WO2010058981A2 WO 2010058981 A2 WO2010058981 A2 WO 2010058981A2 KR 2009006833 W KR2009006833 W KR 2009006833W WO 2010058981 A2 WO2010058981 A2 WO 2010058981A2
Authority
WO
WIPO (PCT)
Prior art keywords
code
hdl
hardware
main core
block
Prior art date
Application number
PCT/KR2009/006833
Other languages
English (en)
Korean (ko)
Other versions
WO2010058981A3 (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 EP09827746.0A priority Critical patent/EP2369476B1/fr
Priority to JP2011537361A priority patent/JP5568566B2/ja
Publication of WO2010058981A2 publication Critical patent/WO2010058981A2/fr
Publication of WO2010058981A3 publication Critical patent/WO2010058981A3/fr

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
    • G06F8/44—Encoding
    • G06F8/447—Target code generation
    • 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/51—Source to source

Definitions

  • the present invention relates to a method and system for converting high-level language code such as C, C ++, Fortran, Java, etc. into HDL code such as Verilog and VHDL, and more specifically, an HDL backend added to a compiler of high-level language code.
  • HDL Hardware Description Language
  • HDL Hardware Description Language
  • It also relates to a framework for cross calls between transformed HDL code running on dedicated hardware and software code running on the main core and recursive calls within the hardware.
  • VLSI very large scale integration technology
  • HDL hardware description language
  • An object of the present invention for solving the above problems is to convert all the high-level language syntax and semantics without modification to the high-level language code to be converted, a method for converting all the high-level language code supported by the main compiler to HDL code Is to provide.
  • Another object of the present invention is to convert all syntax and semantics of all high-level language codes supported by the main compiler of the software into HDL code, and at the same time utilize all the optimizations used in the high-level language code. It is to provide a High-Level Language Code to HDL Code (HDL) converter.
  • HDL High-Level Language Code to HDL Code
  • Another object of the present invention is a compilation to support unlimited recursive calls between cross code and HDL code running on dedicated hardware between software code running on the main core and HDL code running on dedicated hardware. And an execution framework.
  • displaying a translation-targeted section of the high-level language code using a programming directive (2) partitioning a portion to be converted of the displayed high level language code into a hardware portion code and a remaining portion of the high level language code into a software portion code; (3) compiling the software portion code and the hardware portion code by a main compiler, and converting the hardware portion code into HDL code by a high-level language code to hardware description language (HLL-to-HDL) converter; And (4) the software partial code is executed on the main core, and the HDL code is executed on a dedicated hardware.
  • HLL-to-HDL hardware description language
  • said hardware portion code of said step (2) comprises one or more subroutines / functions of said high-level language code to be converted, said software portion code to said hardware portion code Subroutine / function call statement or call instruction.
  • step (3) includes: compiling the software code and hardware code into executable code by a main compiler; Generating a linking log file comprising a constant data offset by the main compiler linker; Generating a symbol table containing addresses of all software functions and variables of the software code executable by the main compiler; And generating the HDL code of the hardware part code by referring to the linking log file and the symbol table by the HLL-to-HDL converter.
  • the HLL-to-HDL converter further utilizes the linking log file and symbol table for address resolution of functions and variables of software defined in the software portion code, and the string constant of the hardware portion code.
  • the linking log file and the symbol table may be used for an address resolution such as a (String constant).
  • the conversion of the hardware partial code into the HDL code by the HLL-to-HDL converter in the step (3) includes: the low level IR (Intermediate) of the step immediately before generating the target assembly code of the main compiler. Representation) code; And converting the low level IR code into an HDL code, wherein the conversion maintains a standard call linkage convention of the main core.
  • the HDL code generated from the subroutine / function of the high level language code may include: a data path generated by mapping from the low level IR code to HDL in the same manner as the target assembly code generation; datapath); And an HDL code generator inside the HDL backend based on control flow information between basic blocks of the low level IR code to control the datapath. It characterized in that it comprises a control unit (control unit).
  • the method of converting the high-level language code of the subroutine / function into HDL includes at least one block module as the data path, basic-block-by- It is characterized in that either the basic-block generation method or the generated HDL code is any one of a function-by-function generation method including one module including both the data path and the control unit.
  • the at least one block module of the basic-block-by-basic-block code generation method performs the same function as the basic blocks of the low-level IR code
  • the top module is a block of the at least one block module. It is characterized by creating an instance and setting the execution order by enabling / disabling the one or more block modules.
  • the block module and the top module of the basic-block-by-basic-block code generation method are in the form of a finite state machine, and one block module is formed inside a basic block of the low-level IR code.
  • the top module of the basic-block-by-basic-block code generation method may enable one or more block modules of the one or more block modules to operate. After assigning and activating an input, waiting for the operation of the one or more block modules to be activated, the activated one or more block modules execute their code with the assigned inputs and execute their own register sets or After storing the output in a register set shared with other block modules, the top module returns the output stored in the register set with a control flow output, and the top module returns the control. Determine which block module to be executed next among the one or more block modules based on the flow output; The.
  • the data path and hardware function control unit of the function-by-function code generation method are included in one HDL module and are implemented as one finite state machine, and the data path of the finite state machine Generates output signals and the control unit controls the state transition of the finite state machine, the datapath being generated from all the basic blocks for subroutines / functions of the high level language and the high level language code Is a set of finite state machines generated from a low level IR instruction of a basic block of subroutines / functions of the state, wherein the state of the finite state machine is based on the delay estimation and data / control dependencies of the low level IR instruction. It is done.
  • control unit of the function-by-function code generation method controls the datapath by changing the state of the finite state machine based on control flow information of a subroutine / function of a high level language code. Characterized in that.
  • the HDL code generated from the high level language code of step (3) shares the memory area including the compiled software code and a stack, follows the software stack layout of the main core, and shares the memory.
  • the region is characterized by being used for storing spilled values, storing register files and return addresses, passing function arguments between the hardware code and the compiled software code.
  • the dedicated hardware of step (4) is generated from the subroutine / function of the high level language code, respectively: HWIP (Hardware identification number) assigned to the hardware identification number (HWID) by the HLL-to-HDL converter. Intellectual Properties set; And a hardware controller controlling the HWIP, wherein the HWID is a target address described in the software portion code and a symbol table of the hardware portion code or a unique number recalculated from the target address. do.
  • the hardware controller controls the HWIPs by passing arguments between the HWIPs and the main core, and controls the HWIPs through the call control signals between the HWIPs and the main core. Controlling the execution order of the main cores, wherein the hardware controller activates one or more HWIPs or main cores according to a call sequence between the HWIPs and the software running on the main cores, and the main core is used as the hardware controller. Characterized in that it can.
  • the communication interface between the main core and the dedicated hardware of step (4) is loosely coupled to the main core and the dedicated hardware so that the dedicated hardware is interrupted with the main core.
  • step (4) includes: executing the compiled software part code on the main core; Activating the hardware controller of the dedicated hardware and transmitting calling data by the main core when execution of one or more of the HWIPs is required while the compiled software portion code is executing; Activating one or more of the HWIPs targeted by the hardware controller of the dedicated hardware and transmitting call data; Executing code of the activated HWIP, storing execution results in a memory and a system register, and notifying the hardware controller of completion of execution of the activated one or more HWIPs; Notifying the main core of completion of execution of the one or more HWIPs activated by the hardware controller; And continuously executing the compiled software portion code with the updated data by the main core.
  • the call data transmitted from the main core to the dedicated hardware includes: a system register including a stack pointer, a link register, an argument register, and other registers dependent on the main core; And a control signal including an HWID and an enable signal of at least one HWIP of interest.
  • one or more arguments of the HWIP to be targeted are transmitted from the main core using arguments of a system register and a stack space shared between the HDL code and the compiled software code. How to convert to code.
  • the main core of step (4) communicates with the dedicated hardware by using a dedicated instruction of an instruction set architecture (ISA) of the main core when the main core and the dedicated hardware are tightly coupled. Or a control signal, and in the case of loose coupling, the main core and the dedicated hardware communicate with the dedicated hardware or transmit a control signal by calling an API function medium that performs a communication function. It features.
  • ISA instruction set architecture
  • the main core updates a register of hardware with its register value.
  • the activated HWIP reads data directly from the main core when the main core and the dedicated hardware is tightly coupled, the main In the case where the core and the dedicated hardware are decoupled, the register value of the hardware controller is read.
  • the hardware controller of the dedicated hardware notifies the main core by interrupting the main core when the main core and the dedicated hardware are uncombined with respect to completion of the execution of the activated HWIP. In the case of tight coupling between the main core and the dedicated hardware, the main core is notified by transmitting a control signal to the main core.
  • the HWIP of the dedicated hardware is capable of performing a cross call to the compiled software portion code executing on the main core, wherein the cross call execution is: compiled to the hard air controller by the HWIP. Preparing calling data and transmitting a control signal to indicate that the software needs to be called; Notifying the main core of the cross call by the hardware controller; Copy the call data into the register of the main core by the main core, execute the code of the compiled software part code called, and if the execution of the called compiled software part code is completed, the hardware controller Notifying to; Notifying the calling HWIP about completion of execution of the compiled software partial code called by the hardware controller; And continuously executing the own code with the execution result of the compiled software part code called by the HWIP.
  • the hardware controller when receiving the control signal from the HWIP, the hardware controller interrupts the main core when the main core and the hardware controller are uncoupled to the cross call.
  • the main core is notified, and in case of tight coupling between the main core and the hardware controller, the main core is notified of the cross call by directly transmitting the control signal to the main core.
  • the main core updates its register with the system register value of the hardware controller and the software part. Writes a return value and a return address of a code into a register of the hardware controller, and when the main core and the hardware controller are tightly coupled, the main core reads an input value directly from the calling HWIP. It features.
  • the HWIP reads the return data and return address of the compiled software part code called from the system register of the hardware controller, and the main core and the hardware controller.
  • the HWIP is characterized in that the return data and return address of the compiled software part code are read directly from the register value of the main core.
  • any one of the HWIPs of the dedicated hardware can make a call to another HWIP or itself, and the call: needs to call the hard air controller by the one HWIP.
  • Preparing calling data to notify the presence of a message and transmitting a control signal Examining a call address by the hardware controller and activating the other HWIP or the one HWIP; Copying the calling data into its register by the other HWIP or the one HWIP, executing its code, and notifying the hardware controller when it is finished executing; Notifying the one HWIP of the completion of execution of the other HWIP or the one of the HWIPs called by the hardware controller; And continuously executing the own code with the execution result of the other HWIP or the one HWIP called by the one HWIP.
  • the call data may also include: a system register including a stack pointer, a link register, an argument register, and a return register; And a control signal including the other HWIP to be called or its own address and an enable signal, wherein the main core and the hardware controller are uncoupled and all the HWIPs are system registers inside the hardware controller.
  • the system registers shared in the hardware controller are updated by the call data by the one HWIP before calling the other HWIP or any one HWIP.
  • the argument of the other HWIP is characterized in that it is transmitted from any one of the registers through the stack and shared between the argument register and the HWIP.
  • the other HWIP updates its register with a system register inside the hardware controller when the main core and the hardware controller are in a loose coupling, and when the main core and the hardware controller are in tight coupling.
  • the other HWIP is characterized in that the read directly register value of any one of the HWIP when activated.
  • the other HWIP when the main core and the hardware controller are uncoupled and all the HWIPs share a set of system registers inside the hardware controller, the other HWIP returns its return value and return address upon completion of execution. It is characterized by writing to a register inside the hardware controller.
  • the one HWIP when the main core and the hardware controller are uncoupled and all the HWIPs share a set of system registers inside the hardware controller, the one HWIP returns a return value and a return address of the other HWIP. Read from a register inside the hardware controller, and when the main core and the hardware controller are tightly coupled, the one HWIP reads the return value and return address of the other HWIP directly from the register of the other HWIP. It is characterized by entering.
  • an HLL-to-HLL source converter which reads the programming directive from a high level language code to be converted indicated by a programming directive and then divides the high level language code into a hardware part code and a software part code;
  • a main compiler for compiling the software part code and hardware part code;
  • An HLL-to-HDL converter for converting the hardware partial code into an HDL code including a data path and control unit;
  • a main core executing the compiled software partial code;
  • a dedicated system for converting the high level language code into the HDL code, including dedicated hardware for executing the HDL code converted in association with the main core.
  • the hardware portion code comprises one or more subroutines / functions of the high level language code to be converted, wherein the software portion code is a function call to the remainder of the high level language code to be converted and to the hardware part code. Characterized in that it comprises a.
  • the HLL-to-HDL converter includes a front end and a middle end and an HDL backend of the main compiler, so that the HLL-to-HDL converter is naturally.
  • the HDL backend is: a machine that maps low-level IR code to HDL with syntax following HDL syntax and semantics Machine description file; And an HDL code generator.
  • the front end and middle end of the main compiler of the HLL-to-HDL converter convert the hardware portion code into a low level IR code
  • the HDL backend of the HLL-to-HDL converter converts the low level IR code into an HDL. It is characterized by converting to code.
  • the generation of the HDL code corresponding to the subroutine / function of the high-level language code includes at least one block module as the data path, basic- including a top module as the control unit block-by-basic-block generation method, or the generated HDL code is characterized in that any one of the function-by-function generation method including a module including both the datapath and the control unit.
  • the data path of the hardware function of the HDL code is generated directly from the low level IR code by the machine description file of the HDL back end, and the control unit of the hardware function of the HDL code is generated by the HDL code generator. Generated based on control dependencies between the basic blocks of code, the data path and the control unit are characterized in the form of a finite state machine (FSM).
  • FSM finite state machine
  • the block module is a set of finite state machines generated from a sequence of consecutive low level IR code instructions, and the state of the finite state machine. Segmentation is based on the delay estimate of the low level IR code instruction and the data / control dependency, the block module performs the same function as the basic block of the low level IR code, and the top module activates / blocks the block module. It is characterized in that the deactivation, and determines the execution order of the block module.
  • the Top module allocates an input to one or more block modules of the one or more block modules so that one or more block modules operate at a time. After activating, wait for the execution of the activated one or more block modules to finish, and the activated one or more block modules execute their code with their assigned inputs and write the output to their register sets. After buffering, the Top module returns the output stored in a register set with a Control Flow Outcome, the Top module based on the control flow output. Determining the block module to be executed next.
  • the data path and the control unit of the generated HDL code corresponding to the subroutine / function of the high level language code are included in one module, Implemented, the data path generates output logic of the finite state machine, the control unit controls a state transition of the finite state machine, and the data path is the high level language.
  • the state partitioning of the finite state machine is based on the delay estimates of the low-level IR code instructions and data / control dependencies. Characterized in that made.
  • the HLL-to-HDL converter in a system for converting a high level language code into an HDL code using an HLL-to-HDL converter, includes:
  • the front end and middle end of the main compiler And a system for converting a high level language code into an HDL code using an HLL-to-HDL converter comprising an HDL backend.
  • the HDL backend comprises: a converter having syntax that conforms to HDL syntax and semantics and which maps low-level IR code to HDL code in the same manner as target assembly code generation; And an HDL generator for generating the HDL code from the low level IR code converted just before generation of the target assembly code from the high level language code by the front end and the middle end of the main compiler.
  • the HDL code generated from the subroutine / function of the high level language code by the HLL-to-HDL converter includes a data path and a control unit, and the data path and the control unit are implemented in a finite state machine form. It is characterized by.
  • the HDL code includes one or more block modules generated from subroutines / functions of the high-level language code as the data path and controls the top module.
  • said HDL code comprises a module comprising both a data path and said control unit.
  • the data path includes one or more block modules, wherein the block module is a set of finite state machines generated from low level IR code instructions of a basic block.
  • the data path is a set of finite state machines generated from the low-level IR code instructions of all the basic blocks of the subroutine / function of the high-level language code. State partitioning of the finite state machine is based on delay estimates and data dependencies of the low level IR code instructions.
  • the system and method for converting high-level language codes to HDL codes according to the present invention can convert syntax and semantics of all high-level languages without modification to the high-level language codes to be converted, so that all high-level language codes supported by the main compiler are HDL codes. There is an advantageous effect convertible to.
  • the application speed is increased by interworking HDL code and software code through cross calls between converted HDL code running on dedicated hardware and software code running on main core, and recursive calls inside the hardware.
  • interworking HDL code and software code through cross calls between converted HDL code running on dedicated hardware and software code running on main core, and recursive calls inside the hardware.
  • FIG. 1 is a structural diagram of a system for converting a high level language code into an HDL code according to an embodiment of the present invention
  • FIG. 2 is a flowchart illustrating a process of converting a high-level language code into an HDL code according to an embodiment of the present invention.
  • FIG. 3 is an exemplary diagram showing a configuration of a system of the present invention when the language to be converted according to an embodiment of the present invention is a C language.
  • FIG. 4 is an exemplary diagram showing the configuration of a system in the case where the conversion target language is a C language according to another embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a process of converting a hardware part code into an HDL code by an HLL-to-HDL converter according to an embodiment of the present invention.
  • FIG. 6 is a block diagram showing control flow and communication between an HDL block module as a data path and a top module as a control unit when using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • FIG. 6 is a block diagram showing control flow and communication between an HDL block module as a data path and a top module as a control unit when using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • FIG. 7 is a block diagram illustrating code generation of a block module of an HDL code from a basic block of a low level IR code when using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • FIG. 8 is an exemplary diagram showing Verilog HDL code of a top module as a control unit in the case of using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • FIG. 9 is an exemplary view showing a top module of Verilog HDL code including an instance of a control unit and a block module in the case of using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • FIG. 10 is a block diagram illustrating a data path and control unit generated from a C function using a function-by-function method in accordance with one embodiment of the present invention.
  • FIG. 11 is a block diagram illustrating communication between a main core and dedicated hardware in accordance with an embodiment of the present invention.
  • FIG. 12 is a flowchart illustrating a calling procedure between a software portion code executed on a main core and a hardware portion code executed on dedicated hardware according to an embodiment of the present invention.
  • FIG. 13 is a block diagram illustrating a SW / HW interface and a hardware controller for supporting a cross call between a software part code and a hardware part code when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention.
  • FIG. 14 illustrates an example of a mechanism for performing a cross call between a software part code executed in the main core and a hardware part code executed in the dedicated hardware when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention. Degree.
  • FIG. 15 is an exemplary diagram illustrating cross call implementation for example code of a cross call between the main core and dedicated hardware of FIG. 14 when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention.
  • FIG. 15 is an exemplary diagram illustrating cross call implementation for example code of a cross call between the main core and dedicated hardware of FIG. 14 when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention.
  • 16 is a block diagram illustrating a communication interface between a main core and dedicated hardware when the main core and dedicated hardware are tightly coupled according to an embodiment of the present invention.
  • 17 and 18 are block diagrams illustrating the cross call implementation of FIG. 16 when the main core and dedicated hardware are tightly coupled according to an embodiment of the present invention.
  • FIG. 1 is a structural diagram of a system for converting a high level language code into an HDL code according to the present invention.
  • the high-level language code conversion system of the HDL code of the present invention is a HLL-to-HLL source converter 110, the main compiler 120, such as GCC (GNU Compiler Collection), the conversion target high-level language code To HLL-to-HDL converter 130 to convert HDL to HDL such as Verilog, main core 140 such as Advanced RISC Machine (ARM), and dedicated hardware 150 such as Field Programmable Gate Array (FPGA). Able to know.
  • GCC GPU Compiler Collection
  • ARM Advanced RISC Machine
  • FPGA Field Programmable Gate Array
  • the HLL-to-HLL source converter 110 reads the programming directive and then converts the hardware part into a hardware part when the programming directive is indicated in the conversion target code section of the high-level language code. Partition into code and software subcode.
  • the hardware part code is a subroutine / function part which is an independent instruction group repeatedly used in a specific or multiple programs among the high level language codes to be converted, and the software part code is the remaining part of the high level language code to be converted and the hardware. Contains function calls to partial code.
  • the main compiler 120 compiles the software part code and the hardware part code partitioned by the HLL-to-HLL source converter 110 and converts them into executable code.
  • the HLL-to-HDL converter 130 serves to convert the hardware partial code partitioned by the HLL-to-HLL source converter 110 into HDL code.
  • the main core 140 and the dedicated hardware 150 serve to execute the software part code compiled by the main compiler 120 and the HDL code converted by the converter 130 in cooperation with each other.
  • FIG. 2 is a flowchart illustrating a process of converting a high-level language code into an HDL code according to an embodiment of the present invention.
  • the method for converting a high-level language code into an HDL code includes displaying a conversion target high-level language code as a programming directive (S210), partitioning the displayed code into a hardware part code and a software part code. Step (S220), compiling the software part code and hardware part code together with the main compiler (S230), converting the hardware part code into HDL code (S240), and the compiled software part code of the main core. It can be seen that the step of executing in (S250) and the step of executing the converted HDL code on the dedicated hardware (S260). At this time, the main core and the dedicated hardware is executed in conjunction with each other.
  • 3 and 4 are exemplary diagrams showing the configuration of the system of the present invention when the language to be converted according to two embodiments of the present invention is a C language.
  • a programming directive such as a pragma is first displayed on a conversion target section of a conversion target code in the C language, which is a high-level programming language.
  • the displayed code part may be a loop (#pragma hardware for part in the drawing), a subroutine (#pragma hardware section), or any part (section) in the conversion target code denoted by #pragma hardware.
  • the HLL-to-HLL source converter 110 then reads the high level language code indicated by the programming directive and converts the code section indicated by the programming directive into a subroutine. The remainder of the high level language code other than the indicated code section corresponds to the software part code.
  • the hardware portion code and software portion code may be stored in one common file, or may be stored in different files.
  • the generated hardware function is named with prefix hw_func_ and HWID number (hardware identification number) (see hw_func_1 in FIG. 4).
  • the extracted code section is replaced by an API function call called a wrapper. Since hardware code does not have an address unlike software, a unique hardware identification number HWID is assigned to each hardware function, and the assigned HWID is used to identify the generated hardware function.
  • the software portion code and the hardware portion code are compiled together by a main compiler 120, such as a GCC compiler, and the hardware functions correspond by the HLL-to-HDL converter 130. Is converted to Verilog code.
  • the general variables and functions arr [10] and printf are declared in software code, they are accessed in hardware with hw_func_1.
  • the hardware cannot know the address of the global variable symbol.
  • the symbol table contains the base addresses of the data section as well as the addresses of all global variables and functions. Therefore, the hardware portion code and the software portion code are compiled together using the symbol table for the address resolution of the global symbol.
  • the address of the constant is calculated as the sum of the three variables. That is, the address of the constant is the start address of the ".rodata” section of the symbol table, the constant's offset address of the input source file to be converted by the HLL-to-HDL converter, and modified according to the present invention. This is determined by the file offset address of the GCC linker.
  • the main compiler compiles the software portion code and the hardware portion code together.
  • the function portion may be excluded when it is not necessary to execute in software in the code optimization of the software portion code compilation process. That is, deadcode elimination may be made.
  • the library function "printf" may be included in the software part code for a call from the "hw_func_1" function of the hardware part code.
  • Hardware compilation also compiles the entire source code to correctly calculate the constant offset information. However, only hardware functions are converted to HDL code such as Verilog, and the remaining sections are ignored by the HLL-to-HDL converter and not converted.
  • the generated HDL code is synthesized by a hardware compiler and executed on dedicated hardware 150, such as an FPGA, while the compiled software part code is executed on a main core 140, such as ARM.
  • FIG. 5 is a flowchart illustrating a process of converting a hardware part code into an HDL code by an HLL-to-HDL converter according to an embodiment of the present invention.
  • the process of converting a hardware partial code in a high level language into an HDL code such as Verilog may include converting the high level language code into a low level IR (Intermediate Representation) such as an RTL code (S410) and a target assembly code ( It can be seen that the step (S420) of generating the HDL code, such as Verilog from the low-level IR code, such as the RTL of the step just before the generation.
  • a low level IR Intermediate Representation
  • RTL code RTL code
  • target assembly code a target assembly code
  • a main compiler front end such as GCC
  • an HLL-to-HDL converter that includes a middle end and an HDL back end.
  • the step of converting the hardware portion code into a low level IR code such as RTL of GCC (S410) is performed by the main compiler front end and middle end of the HLL-to-HDL converter, and from the low level IR code HDL such as Verilog Generating the code is done by the HDL back end of the HLL-to-HDL converter.
  • the HLL-to-HDL converter generates the HDL code by utilizing a low level IR code immediately before being used to generate target assembly code by another back end.
  • the low-level IR code is independent of the input high-level language, the HLL-to-HDL converter can convert the code in all the high-level languages supported by the main compiler into the HDL language.
  • the middle end portion of the GCC compiler is called IR (Intermediate Representation) called RTL to optimize the algorithm before converting the algorithm to assembly language.
  • RTL Intermediate Representation
  • Use GCC's RTL is an abstract description parameterized by a machine description file such as "* .md".
  • the machine description file " *. Md " of GCC defines a target processor such as a functional unit, a register file and an instruction set architecture.
  • the HDL backend according to the present invention is configured such that the instruction pattern conforms to Verilog syntax to facilitate the conversion of the low level RTL to Verilog code.
  • RTL Verilog
  • all memory accesses to C pointers and complex data structures are converted to simple memory accesses, and all kinds of control statements are converted to branches and jump instructions.
  • RTL also follows three-address codes, which can be easily converted to Verilog statements.
  • All RTL operators can also be represented by Verilog operators, and the live-in and live-out registers of the RTL basic blocks can be converted to the Verilog module's input / output data format. Verilog's block modules can communicate with each other through input / output data.
  • the use of registers in RTL corresponds to reg data variables in Verilog.
  • FSM finite state machine
  • the finite state machine can maintain the execution sequence of software while exploiting concurrent execution in hardware.
  • Each state of a finite state machine is uniquely numbered like a program address, and one state represents execution in one clock cycle.
  • One finite state machine state may execute one or more RTL instructions, or in the case of a time-consuming RTL instruction, may be executed over a plurality of finite state machine states.
  • a plurality of instructions in one state may be executed in parallel. The more instructions executed in parallel, the faster the execution of dedicated hardware, such as FPGAs.
  • the HDL backend generates code so that it can be executed across the states of multiple finite state machines.
  • the state variable eg, the processor PC, program counter, etc.
  • Typical hardware systems with the exception of I / O devices and memory systems, include data paths (registers, function units, etc.) and control units for controlling the data paths.
  • the subroutine of the transformed HDL code is converted by the HLL-to-HDL converter to include one data path and one control unit.
  • the data path is implemented with one or more Verilog block modules
  • the control unit is implemented with one Verilog control module.
  • One beryllog block module is constructed from one RTL basic block.
  • FIG. 6 is a block diagram illustrating control flow and communication between an HDL block module as a data path and a top module as a control unit in the case of using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • the RTL code of the function in GCC is divided into several basic blocks, each basic block having only one entry point and one exit point. Have Thus, the flow of control of the code is determined at the end of the basic block. That is, the basic block or preprocessing block currently being executed specifies the basic block or postprocessing block to be executed next to it.
  • the input and output information between the preprocessor and the postprocessor is a resist file. At this time, in executing the postprocessor, the register file updated by the preprocessor is used.
  • the HDL module of the present invention controls the execution of the block modules 560 to 590 and the block module performing the same role as the basic block of the low level IR code such as RTL, and the execution order thereof. It can be seen that it may include a Top module 550 to determine the.
  • the register file of the low level IR code is implemented with input and output signals of the block module.
  • the Top module 550 controls the execution between a plurality of block modules. That is, the Top module assigns an input to the block module to activate the block module, and the activated block module executes its own code with the assigned input, and register set shared with its own block set or another block module.
  • the top module 550 After the output is stored in the buffer, the top module 550 returns the output stored in the register set together with the control flow outcome. The Top module 550 then determines the next block module to be executed based on the control flow output. Using this mechanism, the data path by the block module and the control path by the top module can be separated.
  • a block module including a branch instruction may control branch_result (eg, the result of a comparison instruction) to determine the block module to be executed next. Transmission to the top module 550 corresponding to the. The top module then activates the next block module to be executed via a signal such as enable_bb and helps the activated block module select the correct input from the block module previously executed via its input_select signal.
  • branch_result eg, the result of a comparison instruction
  • the body code of the block module is generated directly from a low level IR code such as an RTL by the machine description file of the present invention.
  • the body code of the Top module is generated by the HDL control generator of the present invention based on the information of the basic blocks of the low level IR code, and the output of the HLL-to-HDL converter of the present invention is several block modules. And one Top module.
  • HDL code generation for the block module of the basic-block-by-basic-block method of the present invention will be described.
  • FIG. 7 is a block diagram illustrating code generation of a block module of an HDL code from a basic block of a low level IR code in the case of using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • Reference numerals 1 to 6 are used to express the one-to-one correspondence of assembly code, RTL instructions, and corresponding Verilog code. Each state of a finite state machine is numbered, and they are shown in the case statement.
  • Each FSM step executes within one clock cycle, so one FSM step can execute one or multiple low-level IR instructions.
  • the condition for instructions to be executed in one step is that the instructions must be in parallel. That is, the instructions must be independent of each other.
  • the HLL-to-HDL converter of the present invention determines how to split low-level IR instructions based on the delay estimation and data dependency of the instructions. Addition, subtraction, assignment, row shift, and logic operations are not time-consuming operations and are considered to be executed in one cycle. If so, many can be included in one FSM step. However, multiplication, division, and memory access are time-consuming tasks, so instructions based on them are executed in the next cycle after waiting for multiplication, division, and memory access to end.
  • state variables "pc” are set to state 0 and registers regs9 and regs10 are input values from the preprocessor (live-in value). ) is initialized to "* _in_4".
  • the variable "pc” represents the state to be executed next, which is similar to the program counter of a general processor.
  • the memory load instruction is executed over two states.
  • state 0 requests memory service
  • state 1 checks memory status and receives data from memory.
  • the instruction of the third state is an addition, which can be executed in parallel with the memory store, which is the instruction of the fourth state. This is because these commands are independent of each other.
  • the memory storage instruction is divided into two states: memory initialization of state 3 (fourth state) and memory status check of state 4.
  • the branch output signal is determined by the value of "regs10" and the finish signal is set to notify the top module, the control module, that the execution has ended.
  • the top module is generated by the HLL-to-HDL converter of the present invention to control the block module and to schedule the execution.
  • the tower module also consists of a finite state machine consisting of states with unique numbers.
  • the top module uses the enable_bb signal to enable / disable the block module.
  • HWID hardware identification number
  • the block module executes its body code with input from its preprocessor block module, and outputs an output value corresponding to the input value of the next block module to be executed. Store in a register set. If the block module is completed with a conditional branch, the branch output is returned to the top module through a successor signal when the block module is completed. The top module considers the branch output to determine the successor block module to be executed next.
  • FIG. 9 is an exemplary diagram illustrating a top module of Verilog HDL code including an instance of a control unit and a block module in the case of using the basic-block-by-basic-block method according to an embodiment of the present invention.
  • the two main tasks of the Top module are to assign inputs / outputs to the block module and to specify the block module's execution schedule.
  • the Top module creates an instance of the block module. This is because the q-block module cannot be used immediately after defining a module, but is merely a structural functional definition, and thus requires instantiation to use the defined module.
  • the Top module assigns the output of the currently executed block module as input to the next block module to be executed.
  • the relationship between the preprocessor and the post processor between the block modules is the same as the relationship between the preprocessor and the post processor between the RTL basic blocks.
  • the Top module is provided with a control unit for determining the execution order of the block modules.
  • the control unit is also implemented in the FSM format (implement), and thus has the following functions. That is, the block module is enabled / disabled by setting enable signals, and an interrupt signal is generated to cause the program (software) to indicate the end of execution.
  • the Top module includes a controller, declares a variable, allocates an input signal to the block module, and generates a block module instance.
  • the controller takes the form of FSM.
  • Verilog code generation of a subroutine of a high-level language code of a function-by-function method will be described.
  • FIG. 10 is a block diagram illustrating a data path and a control unit generated from a C function using a function-by-function method according to an embodiment of the present invention.
  • basic-block-by-basic-block code generation that generates each basic block of the low-level IR code described above with reference to FIGS. 6 to 8 as an HDL block module
  • HDL code generated by the basic-block-by-basic-block method consumes a lot of resources since a separate register file for each block module must be implemented.
  • the generated HDL code requires a large number of registers, thereby depleting resources of dedicated hardware such as FPGAs.
  • a function-by-function method of converting the entire low level IR code of the high level language code into a general datapath may be utilized.
  • the function of the entire high-level language code utilizes only one global register file.
  • the C code and RTL control flow is shown in FIGS. 10A and 10B, and the converted Verilog code corresponding to the C code and RTL control flow, including the control unit and data path, is shown in FIG. 10C. And (d), respectively.
  • the data path and control unit is composed of one finite state machine (FSM).
  • the control unit changes the state variable "nx_pc" value of the finite state machine
  • the data path includes a register file and a functional unit for generating the output of the finite state machine.
  • the HLL-to-HDL converter converts one basic block into a state block of a finite state machine, and the states of all basic blocks are combined to form a global data path. Since a basic block of low level IR code has only one entry point and one exit point, one state block of the corresponding HDL code also has one entry point and exit point.
  • the entry state of the state block is numbered with the corresponding basic block number of the low level IR code. This numbering scheme makes it very easy to change the control flow between the block states. For example, if the control unit wants to jump to the entry code of the basic block 3, it is immediately known that the jump to the state block 3 is required. In addition, if the largest number of the basic block is n, the number up to n is used to number the entry states of the block states, and the number n + 1 is used for the exit state block of the function. Numbers after n + 2 are used for the states inside the basic block.
  • the data path like a normal software function, pushes link and callee-saved registers onto the stack at the start and pops them on end. Even if each hardware function has a separate register file, push and popping are still required to support recursive functions.
  • FIG. 10 (d) An example of a data path implementation is shown in FIG. 10 (d).
  • the RTL code of the hardware function contains five basic blocks from 2 to 6.
  • the link register "reg0” is pushed onto the stack in state 2 and restored in state 16 of state block 5 and state 19 of block 6.
  • the base address of global array C is assigned to "reg9" in state 3, and the loop body calculation is state 4, 12, 13, 14, 15 of block 4. Was run on Array element " c [i] " of the loop in Fig.
  • the generated control unit includes two “always” blocks. That is, it can be seen that it contains two blocks of the next state "nx_pc" in combination with that for the state variable "pc".
  • the jump instruction changes the control flow between the basic blocks. That is, change the state variable "pc". Thus, this is implemented in the control unit, not in the data path.
  • the compare command is used to set the conditions for performing the jump command, and therefore, like the jump command, is excluded from the data path.
  • the comparison operation is checked through continuous assignment, thus minimizing delay due to performance.
  • FIG. 11 is a block diagram illustrating communication between a main core and dedicated hardware in accordance with an embodiment of the present invention. Referring to FIG. 11, it can be seen that the main core and dedicated hardware exchange information through an argument with a control signal such as a memory and an enable signal.
  • a control signal such as a memory and an enable signal.
  • FIG. 12 is a flowchart illustrating a calling procedure between a software part code executed on a main core and a hardware part code executed on dedicated hardware, according to an embodiment of the present invention.
  • the software partial code compiled in the main core is executed at the starting point (S1010), and the software partial code determines whether or not the execution of the hardware intellectual property (HWIP) of dedicated hardware is necessary (S1020), If the execution of dedicated hardware is required to call the dedicated hardware by transmitting the enable signal (enable signal) and parameters to the dedicated hardware (S1030), the activated dedicated hardware executes the called HWIP (S1040), and executes after completion of execution As a result, it can be seen that the main core is notified of the completion of the data update and execution (S1050), and the main core notified of the completion of execution of the dedicated hardware resumes execution of the software partial code with the updated data (S1060). . After that, if the HWIP of the dedicated hardware is no longer needed, the program is terminated.
  • HWIP
  • FIG. 13 is a software (SW) / hardware (HW) interface and hardware controller for supporting a cross call between a software part code and a hardware part code when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention. Is a block diagram.
  • SW / HW interface As shown in FIG. 13, two additional hardware components, a SW / HW interface and a hardware controller, are added to support cross call when the main core and dedicated hardware are loosely coupled.
  • the SW / HW interface module of dedicated hardware is implemented to wrap the software corresponding to the main core so that a constant interface is provided at the cross call.
  • the SW / HW interface module hides the details of the communication from the dedicated hardware to the main core and allows the hardware controller to communicate with the software's main core in the same way as any other hardware component.
  • the hardware identification number (HWID) of the SW / HW is set to a default value of 0 as shown in FIG. 13, and the SW / HW interface may be one of the HWIDs.
  • the hardware controller is implemented to control and schedule the SW / HW interface and hardware components.
  • the hardware controller includes a set of shared registers shared between hardware modules, the set of four registers comprising four argument registers, a hardware stack pointer, and a link register.
  • the hardware controller activates one HWIP at a time, only the activated HWIP is accessible to all system resources, and the other modules are blocked from access (see HW module 1 in FIG. 13).
  • FIG. 14 illustrates an example of a mechanism for performing a cross call between a software part code executed in the main core and a hardware part code executed in the dedicated hardware when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention. It is also.
  • FIG. 14 it can be seen that a programming directive is displayed in the conversion target C code.
  • the "min function” and the "for loop” functions are indicated as conversion targets to the HDL code.
  • the C-to-C source converter generates two hardware subroutines, "hw_func_1" corresponding to "for loop” and “hw_func_2” corresponding to "min function”, as shown in Preprocessed code of FIG.
  • the for loop in the original code to be transformed has been replaced with a call to an API wrapper function to communicate with the dedicated hardware.
  • the first argument of this wrapper function represents the HWID of the called hardware function (eg, the hardware function hw_func_1 for 1), and the remaining arguments represent the variable parameters to be passed to the callee. Details of the wrapper function are shown in FIG. 15 (d).
  • FIG. 15 is an exemplary diagram illustrating cross call implementation of an example code of a cross call between the main core and the dedicated hardware of FIG. 14 when the main core and the dedicated hardware are uncoupled according to an embodiment of the present invention. .
  • the dedicated hardware uses separate system registers from the main core and communicates with the main core through interrupting.
  • the main core also uses an API called a wrapper for communication.
  • FIG. 15 (a) shows an execution flow when an API wrapper function of software calls hardware intellectual property 1 (HWIP1), that is, "hw_func_1", and the execution step is (1). ) To (5).
  • HWIP1 hardware intellectual property 1
  • step (2) the hardware controller activates the HWIP1 module.
  • HWIP1 reads the stack pointer value of the hardware controller and allocates its stack space.
  • HWIP1 stores its return address on its stack from the link register of the hardware controller and starts execution of its bodycode.
  • step (3) when execution of HWIP1 is completed, HWIP1 restores the stack space and sends a finish signal along with a return address to the hardware controller.
  • step (4) the hardware controller sends an interrupt signal to the main core via the SW / HW interface to activate the wrapper function.
  • step (5) the interrupt handler sets a generic termination variable to inform the wrapper function that the execution of HWIP1 has completed, and the wrapper function terminates.
  • 15 (d) shows a pseudo code of the wrapper function.
  • the wrapper function After calling a hardware function, the wrapper function completes the execution of the called hardware function (when the software calls the hardware) or the called hardware calls another software function (the software calls the hardware and then the hardware again). Wait for it to call the software). The wrapper terminates when the called hardware function returns to software, and the wrapper assists the call when the hardware function calls another software function.
  • the hardware controller disables the HWIP1 module and interrupts the main core via the SW / HW interface to call the "max" function.
  • the interrupt handler notifies the wrapper function about the call through a global variable (see hw_called in Fig. 15 (d)).
  • the wrapper function updates the stack pointer of the main core, updates an argument register with the value of the hardware controller, stores the return state of HWIP1 in its local stack, and calls the "max" function.
  • the wrapper function transmits a return value and an end signal of the "max" function to the hardware controller and restores a return state through the SW / HW interface.
  • the hardware controller activates HWIP1 by providing a return state from the link register.
  • HWIP2 activates HWIP2, and HWIP2 stores the return state of HWIP1 on its stack.
  • HWIP2 Upon completion of execution of HWIP2, HWIP2 transmits a termination signal to the hardware controller together with the return state of the called function HWIP1.
  • the hardware controller reactivates HWIP1, and HWIP1 resumes execution in its original state.
  • FIG. 16 is a block diagram illustrating a communication interface between a main core and dedicated hardware when the main core and dedicated hardware are tightly coupled according to an embodiment of the present invention.
  • the interconnection network includes a bus system and a hardware controller for controlling the bus system. All HWIPs and main cores are configured to allow other components to read their register files via the bus system. Public registers include stack pointers, link registers, argument registers, and function return registers. Thus, there is no need for a separate set of system registers in the hardware controller.
  • the interface of the main core allows the hardware controller to directly transmit or receive control signals instead of using an interrupt signal, and the main core and the HWIPs are not connected by an all-to-all network topology. Therefore, when one component wants to communicate with another component, it must communicate through the hardware controller.
  • the hardware controller examines a call control signal of the main core and the HWIP, activates a target component based on a calling sequence according to a decision, and the component is connected to a bus. Allows data transfer. If the main core or the HWIP wants to make a call, it transmits a call control signal and the callee's address to the hardware controller, which checks the call target, deactivates the caller, activates the caller, and clears the caller's register.
  • the caller When the callee returns to the caller, the caller also sends a finish signal and a return address to the hardware controller.
  • the hardware controller checks the return address to verify the caller, allows the bus to read the caller's return data, deactivates the caller, and reactivates the caller.
  • 17 and 18 are block diagrams illustrating the cross call implementation of FIG. 16 when the main core and dedicated hardware are tightly coupled according to an embodiment of the present invention.
  • the main core's interface is modulated to allow better coordination with the dedicated hardware. That is, a special instruction called "hcall" is added to the ISA of the main core to reduce the intermediate step for making a software-to-hardcore call.
  • the main compiler checks whether the callee is implemented in hardware code or software code, and in the case of a hardware function, the main compiler automatically generates an "hcall” instruction instead of a normal function call instruction.
  • the use of the "hcall" instruction allows the main core to directly perform software-to-hardware crosscalls with only one machine instruction. If you do not modify the instruction set, the main core must use an intermediate API function, such as the wrapper function of FIG. 14, to communicate with dedicated hardware, in which case high overhead is inevitable.
  • the "hcall” instruction triggers the "nx_pc_unready” signal to stall the main core pipeline.
  • the signal causes a fetch controller component to stall the instruction fetching process, and the main core sends all instructions after the " hcall " instruction in the pipeline and instruction queue. Flush it.
  • the hardware controller activates the called HWIP1 using the "hw_enable” signal and the control signal "called” based on the received HWID value.
  • the active HWIP1 copies the output values of the main core's stack pointer, argument registers, link registers, etc. into its corresponding registers and starts execution.
  • HWIP1 sends an end signal to the hardware controller, which checks the return address of HWIP1 in the link register to confirm that the caller is the main core.
  • the main controller After confirmation, the main controller transmits a "hw_fin" signal to inform the termination status of the callee HWIP1.
  • the main core activates the fetching process and sets the stack pointer, link and return registers, etc., to the value of the callee.
  • the may core then resumes execution from the return address of the hardware function of the link register.
  • HWIP1 transmits a control signal including a call signal and a "target_addr" signal describing the address of a function to be called to the hardware controller. HWIP1 also stores the address of its next state in its link register, and stores the argument in its argument register and stack space.
  • the hardware controller checks the "target_addr" signal to confirm that the function to be called is a software function of the main core, and transmits a "sw_enable” signal to notify the main core about the call from the hardware function.
  • the main core copies the caller's data over its bus into its register, and its program counter register with the "target_addr” signal value. Set, activate the fetching instructions.
  • the main core Upon completion of execution of the callee, the main core returns to caller HWIP1.
  • the main core does not jump to the target address, unlike the normal software return, but sets the "nx_pc_unready" signal to stall the fetching instructions and flush the pipeline.
  • the hardware return instruction sends a "sw_fin" signal to the hardware controller.
  • the hardware controller checks the link register value to confirm that the caller is HWIP1, and activates HWIP1 with the "hw_enable" signal. If reactivated, HWIP1 reads the callee's return value, updates its state variable in the link register and resumes execution from that state.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention se rapporte à un procédé et un système pour convertir un code en langage de haut niveau tel que C, C++, Java, Fortran, en un code HDL tel que Verilog ou VHDL. Le système selon l'invention comprend un convertisseur HLL - HLL source pour lire la directive de programmation marquée sur un code en langage de haut niveau à convertir, puis séparer le code en langage de haut niveau à convertir en code matériel et code logiciel, un compilateur principal pour compiler les codes matériel et logiciel, un convertisseur HLL - HDL pour convertir le code matériel en code HDL, un noyau processeur principal pour exécuter le code logiciel compilé, et un matériel spécifique pour exécuter le code HDL converti.
PCT/KR2009/006833 2008-11-21 2009-11-19 Procédé et système pour convertir un code en langage de haut niveau en code hdl WO2010058981A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP09827746.0A EP2369476B1 (fr) 2008-11-21 2009-11-19 Procédé et système pour convertir un code en langage de haut niveau en code hdl
JP2011537361A JP5568566B2 (ja) 2008-11-21 2009-11-19 高水準言語コードをｈｄｌコードに変換する方法及びシステム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2008-0116417 2008-11-21
KR20080116417 2008-11-21
KR1020090109753A KR101082797B1 (ko) 2008-11-21 2009-11-13 고수준 언어 코드를 ｈｄｌ 코드로 변환하는 방법 및 시스템
KR10-2009-0109753 2009-11-13

Publications (2)

Publication Number Publication Date
WO2010058981A2 true WO2010058981A2 (fr) 2010-05-27
WO2010058981A3 WO2010058981A3 (fr) 2010-09-23

Family

ID=42197561

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2009/006833 WO2010058981A2 (fr) 2008-11-21 2009-11-19 Procédé et système pour convertir un code en langage de haut niveau en code hdl

Country Status (5)

Country Link
US (1) US8336036B2 (fr)
EP (1) EP2369476B1 (fr)
JP (1) JP5568566B2 (fr)
KR (2) KR101082797B1 (fr)
WO (1) WO2010058981A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10452452B2 (en) 2017-04-17 2019-10-22 Wave Computing, Inc. Reconfigurable processor fabric implementation using satisfiability analysis
CN112400162A (zh) * 2018-07-19 2021-02-23 日立汽车系统株式会社 模拟装置及其方法、以及ecu装置

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5729983B2 (ja) * 2010-11-25 2015-06-03 キヤノン株式会社 情報処理装置、情報処理方法およびプログラム
EP2718859A1 (fr) * 2011-06-08 2014-04-16 Hyperion Core, Inc. Optimisation de code au niveau outil et au niveau matériel et modification matérielle respective
US9043766B2 (en) * 2011-12-16 2015-05-26 Facebook, Inc. Language translation using preprocessor macros
US8650525B2 (en) * 2012-06-22 2014-02-11 Altera Corporation Integrated circuit compilation
US9223553B2 (en) 2013-09-26 2015-12-29 Intel Corporation Methods and apparatus to validate translated guest code in a dynamic binary translator
CN103455362A (zh) * 2013-09-27 2013-12-18 西安电子科技大学 一种硬件语言自动转换系统
US10360006B2 (en) * 2014-03-19 2019-07-23 Nec Corporation Source code generation device, source code generation method, and recording medium
KR101678480B1 (ko) * 2015-07-08 2016-11-22 주식회사 유비콤테크놀로지 Ｒ 언어 기반 빅데이터 처리용 ｆｐｇａ 시스템 및 방법
US10180850B1 (en) * 2015-11-03 2019-01-15 Xilinx, Inc. Emulating applications that use hardware acceleration
US20170168792A1 (en) * 2015-12-15 2017-06-15 Futurewei Technologies, Inc. Space and time aware organization and isolation of components in real time systems
KR101952328B1 (ko) 2017-04-14 2019-02-26 박태영 프로그래밍 언어간 변환 방법
JP7221954B2 (ja) 2017-11-09 2023-02-14 エヌチェーン ライセンシング アーゲー 変更から検証鍵を保護し、正当性のプルーフの有効性を確かめるためのシステム
EP3707872A1 (fr) 2017-11-09 2020-09-16 Nchain Holdings Limited Systèmes et procédés permettant de garantir l'exécution correcte d'un programme informatique à l'aide d'un système informatique médiateur
EP3725028A1 (fr) 2017-12-13 2020-10-21 Nchain Holdings Limited Système et procédé pour partager en toute sécurité du matériel cryptographique
KR101849648B1 (ko) * 2017-12-27 2018-04-17 박동우 건축 설계 모델 제공 방법 및 시스템
KR102263371B1 (ko) 2018-10-30 2021-06-11 한국전자통신연구원 신경망 모델 변환 방법 및 이를 위한 장치
US11347486B2 (en) 2020-03-27 2022-05-31 Advanced Micro Devices, Inc. Compiler-initiated tile replacement to enable hardware acceleration resources
US11553618B2 (en) 2020-08-26 2023-01-10 PassiveLogic, Inc. Methods and systems of building automation state load and user preference via network systems activity
CN114707444B (zh) * 2022-02-09 2023-04-28 芯华章科技股份有限公司 编译验证系统的方法、电子设备及存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6316334A (ja) * 1986-07-08 1988-01-23 Nec Corp 利用者が任意に定義した機械語のインライン展開方式
US5933642A (en) * 1995-04-17 1999-08-03 Ricoh Corporation Compiling system and method for reconfigurable computing
US6751583B1 (en) * 1999-10-29 2004-06-15 Vast Systems Technology Corporation Hardware and software co-simulation including simulating a target processor using binary translation
US6701501B2 (en) * 2000-10-16 2004-03-02 Simon Joshua Waters Structured algorithmic programming language approach to system design
JPWO2002099704A1 (ja) * 2001-05-30 2004-09-16 株式会社鷹山 システム開発支援装置、システム開発支援方法、およびコンピュータ読み取り可能な記録媒体
JP3803561B2 (ja) * 2001-06-29 2006-08-02 松下電器産業株式会社 論理回路設計方法
JP2003114914A (ja) * 2001-10-04 2003-04-18 Sharp Corp ソフトウェア／ハードウェア協調設計方法
KR100488084B1 (ko) * 2002-12-07 2005-05-06 한국전자통신연구원 마이크로 컨트롤러 소프트 아이피 내장용 롬 소프트아이피의 생성 방법 및 이 방법을 실행시키기 위한프로그램을 기록한 기록매체
US7260798B2 (en) * 2003-12-29 2007-08-21 Mentor Graphics Corporation Compilation of remote procedure calls between a timed HDL model on a reconfigurable hardware platform and an untimed model on a sequential computing platform
JP2006011840A (ja) * 2004-06-25 2006-01-12 Mitsubishi Electric Corp 組み込みシステム
JP4473656B2 (ja) * 2004-06-30 2010-06-02 株式会社東芝 紙葉類取り出し装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None
See also references of EP2369476A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10452452B2 (en) 2017-04-17 2019-10-22 Wave Computing, Inc. Reconfigurable processor fabric implementation using satisfiability analysis
CN112400162A (zh) * 2018-07-19 2021-02-23 日立汽车系统株式会社 模拟装置及其方法、以及ecu装置

Also Published As

Publication number Publication date
WO2010058981A3 (fr) 2010-09-23
US8336036B2 (en) 2012-12-18
EP2369476A4 (fr) 2012-08-22
US20100131933A1 (en) 2010-05-27
EP2369476B1 (fr) 2016-01-27
EP2369476A2 (fr) 2011-09-28
KR101082797B1 (ko) 2011-11-14
KR101481453B1 (ko) 2015-01-21
JP2012509537A (ja) 2012-04-19
KR20110093965A (ko) 2011-08-19
KR20100057495A (ko) 2010-05-31
JP5568566B2 (ja) 2014-08-06

Similar Documents

Publication Publication Date Title
WO2010058981A2 (fr) Procédé et système pour convertir un code en langage de haut niveau en code hdl
US20100131934A1 (en) System and method for translating high-level programming language code into hardware description language code
US7533246B2 (en) Application program execution enhancing instruction set generation for coprocessor and code conversion with marking for function call translation
Edwards et al. Balsa: An asynchronous hardware synthesis language
US7853776B2 (en) Handover between software and hardware accelerator
US20010049763A1 (en) Methods and apparatus for scalable array processor interrupt detection and response
US10599404B1 (en) M/A for compiling parallel program having barrier synchronization for programmable hardware
JPH10116302A (ja) 集積回路の設計方法及びそれによって設計された集積回路
US7346863B1 (en) Hardware acceleration of high-level language code sequences on programmable devices
Sadolewski et al. Compiler and virtual machine of a multiplatform control environment
US20080120497A1 (en) Automated configuration of a processing system using decoupled memory access and computation
Kapur et al. Organization of the TRAC processor-memory subsystem
JPH03126133A (ja) コンパイラ処理方法
WO2015102266A1 (fr) Processeur et son procédé de commande
JP3261766B2 (ja) マルチプロセッサシステム、共有変数更新装置、プロセッサユニット及び共有変数更新方法
Bertolotti et al. Embedded software development: the open-source approach
Roos The performance of a prototype coprocessor for Ada tasking
Leupers et al. Retargetable compilers and architecture exploration for embedded processors
WO2018056614A1 (fr) Appareil électronique, processeur et procédé de commande associé
JP2004021907A (ja) 性能評価用シミュレーションシステム
WO2023219204A1 (fr) Procédé de traitement d'instruction et module de processeur associé
Meyer et al. HDL FSM Code Generation Using a MIPS-based Assembler
WO2018066937A1 (fr) Unité d'entrée/sortie de données, appareil électronique et procédés de commande associés
Akella et al. Hierarchical Action Refinement: a methodology for compiling asynchronous circuits from a concurrent HDL
KR20040081030A (ko) 마이크로컴퓨터 응용시스템, 마이크로컴퓨터,신호처리시스템 및 신호처리ｌｓｉ

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

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011537361

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2009827746

Country of ref document: EP