High-Level-Synthesis for RISC-V System-on-Chip Generation for Field Programmable Gate Arrays

An article of manufacture includes a medium with instructions that when read and executed by a processor, cause the processor to identify a code stream to be executed by a system-on-a-chip (SoC). The SoC is to include an open standard processor and hardware accelerators implemented in reprogrammable hardware. The processor is to, from the code stream, identify a first portion of the code stream to be executed as software by the open standard processor and a second portion to be executed in the accelerators, compile the first portion into a binary for execution by the open standard processor, and generate a hardware description for the second portion to be implemented by the hardware accelerators. The hardware description and the binary are to exchange data during execution of the code stream.

FIELD OF THE INVENTION

The present disclosure relates to reconfigurable microprocessor and microcontroller architecture and, more particularly, to high-level-synthesis (HLS) for RISC-V system-on-chip (SoC) generation for field programmable gate arrays (FPGA).

BACKGROUND

FPGAs may include SoC devices, wherein a processor exists on the same die as the FPGA fabric. SoC FPGAs may pose challenges that have been discovered by inventors of examples of the present disclosure. Having a processor enables software engineers to use the FPGA, but software engineers may be limited to using the processor and not the FPGA fabric, lacking hardware expertise and knowledge of hardware description languages (HDL). HLS may allow a software program to be compiled into a hardware circuit which is in turn described in an HDL. However, integrating a hardware core (such as an accelerator) into a processor system also uses hardware knowledge, making SoC design infeasible for many software engineers.

Moreover, implementing a high-performance SoC design may rely upon careful consideration and implementation of data transfers between processor and hardware logic. Depending on the amount of data transfer, different transfer methods can be beneficial, and it can be difficult for a user to know which data transfer method to use. For large data transfers (i.e., over 16 KBs), DMA (direct memory access) can be beneficial. However, this may have a predicate step to configure DMA engine that can burst large amounts of data from off-chip double data rate (DDR) memory. This might not be possible for software engineers.

SoC designs may also pose new challenges for hardware engineers, as interfacing and integrating an SoC design can be time-consuming and error-prone. An SoC design has software and hardware components, which may have a predicate step of setting up data transfers between them.

Hardened processors in an SoC may include application-specific integrated circuits (ASIC), mixed signal implementations, or other non-FGPA implementations. Hardened processors can run an operating system (OS), which provides virtual memory and pages. Pages can cause data to be in physically non-contiguous regions, which make DMA transfers difficult. Ensuring data to be in physically contiguous memory regions with an OS can be a difficult task for hardware engineers.

Examples of the present disclosure may address one or more of these issues identified by inventors of examples of the present disclosure.

DETAILED DESCRIPTION

FIG.1is an illustration of a system100for HLS for SoC generation for FPGAs, according to examples of the present disclosure.

System100may include an article of manufacture. The article of manufacture may include a non-transitory machine-readable medium. The medium may be implemented by, for example, any suitable memory. The medium may include instructions104. Instructions104, when read and executed by a processor102, may cause the processor to generate a SoC at least partially in an FPGA. Instructions104as read and executed by processor102may in effect implement a compiler of an SoC, such as SoC112.

Based upon instructions104, processor102may identify a code stream106. Code stream106may include any suitable contents, such as instructions, hardware descriptors, object code, programming language constructs, settings, or other suitable contents. Code stream106may be configured to be compiled, assembled, interpreted, or otherwise processed so as to be executed by SoC112. Part of execution of code stream106by SoC112may include forming or defining parts of SoC112in reconfigurable hardware116. Reconfigurable hardware116may be implemented by, for example FPGA fabric.

SoC112may include reconfigurable hardware116. Moreover, SoC112may include a processor114. Processor114may be an open standard instruction set architecture (ISA) processor. Specifically, processor114may be an RISC-V processor. Moreover, SoC112may include any suitable number and kind of accelerators118. Accelerators118may include circuits designed to perform specific or specialized tasks, such as graphics processing, cryptography, mathematical computations, bitcoin mining, or any other tasks that may be offloaded from a processor. Accelerators118may be implemented within reprogrammable hardware116. Moreover, in some examples, processor114may be implemented within reprogrammable hardware116, while in other examples processor114may be implemented outside of reprogrammable hardware116.

Instructions104may cause processor102to, from code stream106, identify a first portion108of code stream106to be executed as software by processor114. Instructions104may cause processor102to, from code stream106, identify a second portion110of code stream106to be executed in accelerators118. The execution may be performed by direct execution by processor114or by arrangement of programmed circuitry in programmable hardware116.

Instructions104may cause processor102to compile first portion108of code stream106into a binary120for execution by processor114. Instructions104may cause processor102to generate a hardware description122for second portion110of code stream106. Based upon code stream106, hardware description122and binary120may be configured to exchange data during execution of code stream106in SoC112.

Processor102may load binary120and hardware description into SoC112. Other portions of code stream106may also be loaded into SoC112. Such other portions may be compiled or generated into hardware descriptions, as well as any other suitable portion of SoC112such as memories, peripherals, or interconnects. These may be loaded onto SoC112or configured in SoC112.

Code stream106may include a C or C++ program. Code stream106may be partitioned into software and hardware partitions. First portion108may come from such software partitions and second portion110may come from such hardware partitions. Hardware partitions of code stream106may be compiled into hardware descriptions such as hardware description122that are written in, for example, HDL. The software partition may be compiled into binaries for execution on a RISC-V processor.

FIG.2is a more detailed illustration of SoC112, according to examples of the present disclosure.

SoC112may include peripherals134. Peripherals134may be formed within reprogrammable hardware116. Peripherals134may include any suitable circuits for facilitating operation of SoC112such as counters, pulsed-width modulation circuits, communication circuits for a given protocol such as serial or I2C bus interfaces, or timers.

Processor114may include an operating system126. Operating system126may be configured to execute binary120.

SoC112may include a memory controller circuit128. Moreover, SoC112may include a memory integrated with memory controller circuit128or externally accessible as memory130. Memory controller circuit128and memory may be formed within reprogrammable hardware116. Memory controller circuit128may include a direct memory access (DMA) engine. Such memory may be a DDR memory.

Data access between the elements of SoC112may be made across any suitable number and kind of hardware interfaces132. Hardware interfaces132may be formed within reprogrammable hardware116. Hardware interfaces132may be implemented by, for example, switch fabric within reprogrammable hardware116.

Data transfers between memory, such as within memory controller circuit/memory128or memory130, and accelerators118can be handled automatically, wherein processor102generates driver functions from code stream106to transfer data to or from accelerators118and control accelerators118.

Elements that may be formed within reprogrammable hardware116may be defined in code stream106and implemented by a hardware description, such as hardware description122, as applied to reprogrammable hardware116.

FIGS.3A and3Bare illustrations of possible implementations of processor114, according to examples of the present disclosure.

FIG.3Aillustrates an implementation of processor114as a soft processor, wherein code stream106defines the architecture of processor114and processor114is implemented within reprogrammable hardware116.

FIG.3Billustrates an implementation of processor114as a hardened processor, wherein processor114is implemented as a physical processor or ASIC outside of reprogrammable hardware116. Processor114may utilize a processor socket302. Processor socket302may also include components for interfacing processor114with the remainder of SoC112, such as a hardware interface switch304for interfacing with hardware interfaces132to send data to, for example, accelerators118. Processor socket302may include a DMA engine308for receiving memory outputs from, for example, accelerators118. Processor socket302may include a cache306and a DDR controller circuit310.

Processor102, based upon instructions104, may be configured to selectively generate binary120for processor114as implemented as a hardened processor in SoC112as shown inFIG.3Bor for processor114as implemented as a soft processor in reprogrammable hardware116of the SoC as shown inFIG.3A. Generating binary120for processor114as implemented as a soft processor in reprogrammable hardware116may be accompanied by generating hardware description122for processor114.

FIG.4is a more detailed illustration of generating hardware description122and binary120by processor102, according to examples of the present disclosure.

Code stream106, as discussed above, may include a C or C++ program or set of instructions. Code stream106may include specification of one or more functions that are to be accelerated by accelerators118.

Processor102may include or execute a compiler402, driver generation404, hardware partitioning406, hardware optimization408, and hardware generation410. Each of compiler402, driver generation404, hardware partitioning406, hardware optimization408, and hardware generation410may be implemented by instructions104for execution by processor102.

Compiler402may cause object code or other suitable executable code to be generated as transformed software and implemented in binary120. Compiler402may be implemented by, for example, Clang or any suitable frontend compiler to transform an input program in code stream106to call software driver functions to invoke accelerators118rather than perform such functions in software executed by processor114. Moreover, driver generation404may cause any suitable software drivers to be added to or linked with binary120. These software drivers may include drivers to invoke accelerators118instead of executing such functions in processor114. Moreover, in various examples, these software drivers may handle data transfers to and from memory and accelerators118, and retrieve computed results. The transformed software from compiler402and the software drivers generated by driver generation404may form binary120or the software partition to be executed by processor114. The software partition may be compiled with an RISC-V compiler toolchain to be executed RISC-V compiler.

Hardware partitioning406, hardware optimization408, and hardware generation410may cause a hardware design412to be generated. Any suitable add-in's, such as from libraries for generation of common components, may be added to hardware design412to yield hardware description122. Hardware generation410may cause generation of descriptions of accelerators118in HDL. Scripts for integrating hardware, such as those written in Tcl, may be generated. The scripts may have commands for integrating hardware such as accelerators118with any additional circuits or components to form a complete SoC112.

FIG.5is a more detailed illustration of generating hardware description122, according to examples of the present disclosure.

Processor102may be configured to be able to generate different hardware data transfer architectures in SoC112by way of hardware description122. Processor102may be so configured by different settings502set by users, or by different instructions in second portion110. These may contain a user-specified transmission method for data exchange between binary120and hardware description122. These different architectures are discussed in more detail inFIGS.7-9, below.

FIG.6is a more detailed illustration of generating a binary120that defines allocations of contiguous memory, according to examples of the present disclosure.

Processor102may be configured to generate binary120to allocate a contiguous block606of memory6-4for use by processor114, based upon a contiguous allocation command602in code stream106.

FIG.7is an illustration of defining possible data transfers in SoC112according to instructions in code stream106, according to examples of the present disclosure.

Code stream106may include any suitable number and kind of transfer instructions, including a first transfer instruction702, a second transfer instruction704, and a third transfer instruction706.

Accelerator118may include a core712, which may include circuitry to perform the specialized acceleration computation for which execution is offloaded from processor114to accelerator118. Accelerator118may include a buffer710, which may optionally store results from core712, depending on a defined architecture for hardware description122, which may in turn depend upon which transfer instruction among transfer instructions702-706is used to define data transfer for the given instance of accelerator118.

In the examples ofFIGS.7-9, processor114can be implemented within reprogrammable hardware116or outside of reprogrammable hardware.

SoC112may include a DMA core708. DMA core708may be implemented within reprogrammable hardware116or outside of reprogrammable hardware. DMA core708may be configured to manage access to actual memory (not shown) which may be implemented reprogrammable hardware116or outside of reprogrammable hardware. DMA core708may be an implementation of memory controller circuit128. DMA core708may implement DMA engine circuit300.

A user may define the preferred data transfer architecture or method for a given instance of accelerator118through selection of a specific one of transfer instructions702-706to be executed. Selection of a specific one of transfer instructions702-706may cause associated software drivers to be included in binary120and associated hardware architecture to be implemented in hardware description122.

Processor102may be configured to, based upon first transfer instruction702in code stream106, generate hardware description122and compile binary120to cause processor114and hardware accelerator118to exchange data during execution of code stream106through buffer710with DMA core circuit708.

Processor102may be configured to, based upon second transfer instruction702in code stream106, generate hardware description122and compile binary120to cause processor114and hardware accelerator118to exchange data during execution of code stream106through buffer710in the reprogrammable hardware without DMA use. Thus, DMA use of DMA core circuit708may be selectively enabled or disabled for use in data transfer.

Processor102may be configured to, based upon first transfer instruction702in code stream106, generate hardware description122and compile binary120to cause processor114and hardware accelerator118to exchange data during execution of code stream106through a bypass of buffer710in reprogrammable hardware116. Thus, buffer710may be selectively enabled or disabled for use in data transfer.

FIG.8is a more detailed illustration of accelerator118with various data transfer implementations, according to examples of the present disclosure.

Accelerator118may include any suitable number and kind of connections to the rest of SoC112. In the example ofFIG.8, two possible connections are shown. These connections may be implemented through hardware interfaces132. The connections may be implemented according to the Advanced eXtensible Interface (AXI) standard. A connection may be provided directly to compute core810(which may be an implementation of core712) through hardware interface132B. Such a connection may be referred to as AXI initiator822(also known as an AXI manage). AXI initiator822may be an interface used by compute core810to directly access data outside of accelerator118. AXI initiator822can write to external memory and read data back. A connection may be provided indirectly to compute core810, routed through a buffer804(which may be an implementation of buffer710). Such a connection may be referred to as AXI target820(also known as an AXI subordinate). AXI target820may be an interface used by processor114to write data to the on-chip buffers806,808and read data back. Processor114may initiate these transactions.

Buffer804may include any suitable number and kind of on-chip buffers. For example, buffer804may include on-chip buffer806and on-chip buffer808. On-chip buffer806and on-chip buffer808may be respectively referenced in code stream106as “argA” and “argB” when the respective on-chip buffer is to be used for a given execution or data exchange.

Compute core810may be configured to provide its results through buffer804, and through a respective one of the on-chip buffers therein through designation in a command of code stream106that uses argA or argB. From there, DMA core engine circuit708may be configured to collect the results through hardware interface132A and transfer the results to other memories or otherwise make the results available to processor114. Compute core810may be configured to provide its results directly through hardware interface132B to any other part of SoC112, such as processor114.

Compute core810may include any suitable number and kind of functions that are to execute tasks as specified in code stream106, which may be invoked through software drivers in binary120. For example, compute core810may include an accel function812and a sub_accel function814. Compute core810may include any suitable number and kind of on-board memories816.

Users may select which mechanism is used for data transfer by changing a parameter, such using argA, arbB, or argC in code stream106.

By default, the driver functions may invoke a data exchange to transfer data with the C “memcpy function”, which performs copying by processor114. This may include use of argC. For larger data transfers, DMA core circuit708can transfer data in bursts using a DMA copy method for higher bandwidth transfer. This type of data transfer may use AXI Target interface820to write/read data to/from on-chip buffers804,806. For low latency memory accesses, accelerator118can also access DDR memory directly using an accelerator direct access method. Compute core810uses AXI initiator822to do this.

An example segment of pseudo-code that may represent instructions in code stream106that can be offloaded for execution at least in part by accelerator118may be:

The “HLS” terms in the code may denote that the process of generating hardware description122and binary code120is to be followed so as to create accelerator118in SoC112to execute “accel_function” (812) when so invoked in code stream106. “HLS” may stand for “high level synthesis” to denote this process. The use of pragmas may be used to specify which functions are to be accelerated to hardware in accelerators118. Thus, code stream106may specify the top-level function of a given instance of hardware accelerator118with the pragma, “#pragma HLS function top”. Processor102may be configured to take this function (“accel_function”) and its descendent functions (such as “sub_accel_function”) to be compiled into an instance of accelerator118and specified by hardware description122. Any suitable number and kind of functions may be specified with the “function top” pragma, each of which may become an instance of accelerator118.

The interface for a given instance of accelerator118may be automatically generated based on contents of code stream106, such as user-provided pragma and accelerator function arguments. For example, the pragma “#pragma HLS interface default type(axi_target)” indicates that an AXI target interface may be generated for accelerator118. When an AXI target interface is used, an AXI target adapter may be instantiated, which may contain memories for where the accelerator's function arguments from DDR memory can be transferred. Processor102may analyze the arguments to generate the type of memory to use. For scalar function arguments (i.e., integers), the arguments may be stored in registers. For pointers, arrays, and structures, arguments may be stored in on-chip buffers such as buffers806,808. Compute core810may read arguments from buffers806,808s to perform computations as well as write computed results back to buffers806,808. Compute core810may also have local memories816for data not shared with other components of SoC112. When accelerator118finishes running, the computed results may be retrieved from on-chip buffers806,808back to memory by processor114or DMA engine circuit708, depending on type of transfer method being used. By default, processor114may be configured to transfer the data to and from on-chip buffers806,808.

However, with a pragma such as “dma(true)”, a user can specify in code steam106that DMA engine708is to perform the data transfer. The “dma(true) option might only be valid for when the interface for the argument is specified as AXI Target, as the DMA transfer data is to on-chip data buffers. For example, “#pragma HLS interface argument(argA) type(axi_target) dma(true)” may be used.

FIG.8shows implementations of three different interface pragmas to illustrate transfer methods of CPU copy, DMA copy, and accelerator direct access. These may include methods specified variously by:

With the “dma(true)” pragma option for argument “argA”, code stream106may specify that the argument is to be transferred to and from buffer806with a DMA engine such as DMA engine circuit300or DMA core708. Processor102may set up operation of DMA engine circuit300or DMA core708and generate driver code for DMA engine circuit300or DMA core708to perform the data transfer. This may be included in binary120.

With the lack of a “dma(true)” pragma option for argument “arbB”, a CPU copy method may be used to transfer data to and from buffer808without a DMA engine, and instead performed by processor114.

For “argC”, the “axi_initiator” option may cause an accelerator direct access method to be used by creating an AXI Initiator (i.e., AXI Manager) interface in accelerator118, wherein compute core810directly accesses the cache of processor114and SoC memory such as a DDR memory. This method may be used, for example, when data needs to be streamed directly into compute core810without being buffered. This may also reduce on-chip memory usage, as on-chip buffers806,808might not be required.

Below is example code for a software partition that may be run on processor114as part of binary120, including the generated driver functions for functions for accelerator118. This example code may be run on a Linux operating system, which may use the “hls_alloc” library for arguments using DMA copy or accelerator direct access methods. In the Linux operating system, when data needs to be transferred via DMA, or when accelerator118directly accesses DDR memory, it may be a requirement that accessed data resides in a physically contiguous memory region. Accordingly, the “hls_malloc” function may be called to allocate contiguous memory regions for the arguments. The “hls_malloc” function may have the same function signature as the standard C “malloc” function used to allocate memory in C. Allocated memories may be freed with, for example, the function “hls_free”, which has the same function signature as the standard C “free” function. The “hls_alloc” and “hls_free” functions might be used for DMA transfers and accelerator direct accesses, but might be unnecessary for when processor114copies the data with “memcpy” (i.e., a CPU copy method).

Given the “accel_function” designated for hardware acceleration, processor102may transform the body of accel_function to call the generated “accel_function_hls_driver” function. For conciseness, the high-level structure of the driver functions is described but not all definitions of the sub-function are shown. The top-level driver function, “accel_function_hls_driver”, may call two sub-functions, “accel_function_write_input_and_start” and “accel_functionjoin_and_read_output”. The “accel_function_write_input_and_start” function may set up the accelerator function, transfers the arguments, and starts the accelerator. For the “argA” argument, which was specified in the pragma as DMA Copy, the “accel_function dma write argA” function transfers 16 bytes from the argA pointer via DMA. For the “argB” argument, which defaults to the CPU Copy method, processor114may transfer the 16 bytes of data from the argB pointer with the memcpy function call. For the “argC” argument, which will be directly accessed by accelerator118, only the pointer address needs to be given to accelerator118with the “accel_function_write_argCptr_addr” function. After all argument data are transferred, accelerator118may be called.

The “accel_functionjoin_and_read_output” function may call the “accel_functionjoin” sub-function, which may check if accelerator118has finished execution. If finished, the sub-function may retrieve the return value from accelerator118. This example might not have any output arrays which are written to by accelerator118. If any output arrays exist, they can be copied back by processor114or DMA engine circuit300or DMA core708, or can be written to memory directly by accelerator118. Finally, the return value may be returned to the top-level driver function, which subsequently returns it to the accelerator function.

SmartHLS also generates Tel scripts to automate the process of integrating hardware accelerators into its target Soc design. SmartHLS analyzes the hardware functions to determine what types of interfaces are required and how much address space is needed based on the accelerator function's arguments—the bigger the sizes of arguments, the bigger the address space. It assigns appropriate memory mapped addresses for each accelerator and invokes SmartDesign with the generated Tel script to integrate the accelerators to an SoC design with the RISC-V processor system, memories, interconnect, and peripherals. This integration process is completely automated and requires no user intervention.

FIG.9is an illustration of an example method900for generating an SoC, according to examples of the present disclosure. Method900may be performed by any suitable elements, such as those of system100as shown inFIGS.1-8. For example, method900may be performed by processor102. Method900may be executed with more or fewer steps than shown inFIG.9, and the steps of method900may be optionally omitted, repeated, performed in a different order, performed in parallel, or recursively.

At905, a code stream to be executed by an SoC may be identified. The SoC may include an open standard ISA processor and a hardware accelerator implemented in reprogrammable hardware.

At910, a first portion of the code stream to be executed as software by the open standard ISA processor of the SoC and a second portion of the code stream to be executed in the hardware accelerators of the SoC may be identified.

At915, the first portion of the code stream may be compiled into a binary for execution by the open standard ISA processor of the SoC. At920, it may be determined whether the processor is a hardened processor or a softened processor. If the processor is a hardened processor, then at920a binary may be generated for the hardened processor. If the processor is a softened processor, then at925a binary may be generated for the softened processor. Moreover, in later steps, such as940, a hardware description for the processor may be generated.

At935, the binary may be generated to allocate a contiguous block of memory for use by the open standard ISA processor, based upon a contiguous allocation command in the code stream.

At940, a hardware description for the second portion of the code stream to be implemented by the hardware accelerators may be generated, wherein the hardware description and the binary are to exchange data during execution of the code stream. The hardware architecture of the hardware description may be generated based upon a user-specified transmission method of exchanging data between the hardware description and the binary.

At945, based upon a first transfer instruction in the code stream, the hardware description may be generated, and the binary compiled to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream through a buffer in the reprogrammable hardware with a direct memory access core.

At950, based upon a second transfer instruction in the code stream, the hardware description may be generated, and the binary compiled to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream through a buffer in the reprogrammable hardware without director memory access.

At955, based upon a third transfer instruction in the code stream, the hardware description may be generated, and the binary compiled to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream directly through a bypass of a buffer in the reprogrammable hardware.

Examples of the present disclosure may include an article of manufacture. The article may include a non-transitory machine-readable medium. The medium may include instructions. The instructions, when read and executed by a processor, may cause the processor to identify a code stream to be executed by a SoC. The SoC may include an open ISA processor and one or more hardware accelerators implemented in reprogrammable hardware. The instructions may cause the processor to, from the code stream, identify a first portion of the code stream to be executed as software by the open standard ISA processor of the SoC and a second portion of the code stream to be executed in the one or more hardware accelerators of the SoC. The instructions may cause the processor to compile the first portion of the code stream into a binary for execution by the open standard ISA processor of the SoC. The instructions may cause the processor to generate a hardware description for the second portion of the code stream to be implemented by the hardware accelerators. The hardware description and the binary are to exchange data during execution of the code stream.

In combination with any of the above examples, the processor may be to selectively generate the binary for the open standard ISA processor as implemented as a hardened processor in the SoC or the open standard ISA processor as implemented as a soft processor in the reprogrammable hardware of the SoC.

In combination with any of the above examples, the processor may be to selectively generate a hardware architecture of the hardware description based upon a user-specified transmission method of exchanging data between the hardware description and the binary.

In combination with any of the above examples, the processor may be to generate the binary to allocate a contiguous block of memory for use by the open standard ISA processor, based upon a contiguous allocation command in the code stream.

In combination with any of the above examples, the processor may be to, based upon a first transfer instruction in the code stream, generate the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator of the one or more hardware accelerators to exchange data during execution of the code stream through a buffer in the reprogrammable hardware with a direct memory access core.

In combination with any of the above examples, the processor may be to, based upon a second transfer instruction in the code stream, generate the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream through a buffer in the reprogrammable hardware without direct memory access.

In combination with any of the above examples, the processor may be to, based upon a third transfer instruction in the code stream, generate the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream directly through a bypass of a buffer in the reprogrammable hardware.

Examples of the present disclosure may include an SoC generated by any of the above examples, including execution of the instructions in any of the above articles of manufacture.

Examples of the present disclosure may include an SoC with an open standard ISA processor and one or more hardware accelerators implemented in reprogrammable hardware. The open standard ISA processor may be to execute a binary generated from a first portion of a code stream. A second portion of the code stream may be implemented by a hardware description in the hardware accelerators. The hardware description and the binary may be used to exchange data during execution of the code stream.

In combination with any of the above examples, the open standard ISA processor may be implemented as a soft processor in the reprogrammable hardware of the SoC.

In combination with any of the above examples, the binary may be to allocate a contiguous block of memory for use by the open standard ISA processor based upon a contiguous allocation command in the code stream.

In combination with any of the above examples, the open standard ISA processor and one of the hardware accelerators may be to, based upon a first transfer instruction in the code stream, exchange data during execution of the code stream through a buffer in the reprogrammable hardware with a direct memory access core.

In combination with any of the above examples, the open standard ISA processor and one of the hardware accelerators may be to, based upon a second transfer instruction in the code stream, exchange data during execution of the code stream through a buffer in the reprogrammable hardware without director memory access.

In combination with any of the above examples, the open standard ISA processor and one of the hardware accelerators may be to, based upon a third transfer instruction in the code stream, exchange data during execution of the code stream directly through a bypass of a buffer in the reprogrammable hardware.

Examples of the present disclosure may include a method performed by any of the above examples, including execution of the instructions in any of the above articles of manufacture or performance of any of the above SoCs.

Examples of the present disclosure may include a method. The method may include identifying a code stream to be executed by an SoC. The SoC may include an open standard open standard ISA processor and one or more hardware accelerators implemented in reprogrammable hardware. The method may include, from the code stream, identifying a first portion of the code stream to be executed as software by the open standard ISA processor of the SoC and a second portion of the code stream to be executed in the hardware accelerators of the SoC. The method may include compiling the first portion of the code stream into a binary for execution by the open standard ISA processor of the SoC. The method may include loading the binary onto the SoC, generating a hardware description for the second portion of the code stream to be implemented by the hardware accelerators, and loading the hardware description onto the SoC. The hardware description and the binary may be used to exchange data during execution of the code stream.

In combination with any of the above examples, the method may include selectively generating the binary for the open standard ISA processor as implemented as a hardened processor in the SoC or open standard ISA processor as implemented as a soft processor in the reprogrammable hardware of the SoC.

In combination with any of the above examples, the method may include selectively generating a hardware architecture of the hardware description based upon a user-specified transmission method of exchanging data between the hardware description and the binary.

In combination with any of the above examples, the method may include comprising generating the binary to allocate a contiguous block of memory for use by the open standard ISA processor, based upon a contiguous allocation command in the code stream.

In combination with any of the above examples, the method may include, based upon a first transfer instruction in the code stream, generating the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream through a buffer in the reprogrammable hardware with a direct memory access core.

In combination with any of the above examples, the method may include, based upon a second transfer instruction in the code stream, generating the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream through a buffer in the reprogrammable hardware without director memory access.

In combination with any of the above examples, the method may include, based upon a third transfer instruction in the code stream, generating the hardware description and compile the binary to cause the open standard ISA processor and a first hardware accelerator to exchange data during execution of the code stream directly through a bypass of a buffer in the reprogrammable hardware.

Although examples have been described above, other variations and examples may be made from this disclosure without departing from the spirit and scope of these examples.