Configurable hardware accelerators

In various embodiments, a configurable hardware accelerator is provided. The configurable accelerator may include a transmit direct memory access (DMA) engine, a receive DMA engine, and one or more execution engines. In those embodiments, the configurable accelerator can be configured to access a shared data storage in a continuous mode. The transmit and receive DMA engines can be configured to transmit data from one location in the shared data storage to a different location in the memory storage. The execution engine(s) can be configured to perform a wide range of functions on the data accessed by the transmit DMA engine(s) in streaming fashion. In those embodiments, the data are accessed and processed by the configurable accelerator in a streaming manner to speed up the data processing performance.

TECHNICAL FIELD

The present disclosure relates generally to computation acceleration.

BACKGROUND OF THE INVENTION

In developments of emerging technology, such as new wireless standards or Artificial Intelligence, the amount of data required to be processed is increasing substantially. With the profusion of data, more computational requirements are placed on general purpose CPUs, specialized CPUs (i.e. GPU, TPU) and/or specialized Hardware Accelerators to expeditiously process the data.

As the computational requirement placed on the processors increases, the performance of the processors is often inadequate to handle computationally intensive tasks on large amount of data. In some cases, even if specialized processors are capable of handling the computational requirements, the cost of such processors is often prohibitive for many applications.

There are various factors which limit the computational capabilities of a processor. Traditionally, the processors use internal registers to temporarily hold the source input data which are loaded from the data memory. The processor then performs an arithmetic or other programmed operation using the values stored in the temporary registers as the operands, and writes the result of the operation to another temporary register. Finally, the processor stores the result in the temporary register back to the data memory.

For performing such operations, many instructions are required. For example, ADD Immediate instructions to calculate the operand addresses; LOAD Instructions to load the operands; MULTIPLY instruction to multiply the operands; ADD Immediate instruction to calculate the destination address; and STORE instruction to write the result to the destination memory location.

During the execution of these instructions, due to the inherent load/store latency associated with the data memory and the limited availability of the temporary registers, the instruction executions are often blocked by pipeline stalls resulting in degraded processor performance. The problem of pipeline stall is compounded when the processor operates on large sets of data.

Other common techniques employed in the industry, such as SIMD and Vector Instruction Extensions, try to address the performance issue by parallel data processing. However, these techniques, even though they obtain performance increase through parallelism, are still subject to the aforementioned limitations.

Therefore, it is desirable to have a flexible solution capable of processing large amount of data, which can also be quickly programmed, deployed, and modified as the product matures.

BRIEF SUMMARY OF THE INVENTION

Through various embodiments disclosed herein, a configurable accelerator is described. The configurable accelerator in accordance with the disclosure can provide a flexible solution for processing large amounts of data, thus reducing or eliminating pipeline stalls that may degrade the processor performance. The configurable accelerator in accordance with the disclosure may include a transmit direct memory access (DMA) engine (TXDMA), a receive DMA engine (RXDMA), one or more address generator units (AGU), an execution engine (XE), and/or any other components. In some embodiments, the configurable accelerator can be connected to a shared data storage along with one or more processors or any other entity using the configurable accelerator. In some embodiments, the shared data storage memory may be partitioned into multiple memory banks. In those embodiments, each memory bank can be independently accessed by the configurable accelerator and/or processors connected to the shared data storage memory for read or write operations. The access to the shared data storage memory can be controlled by one or more arbiters associated with each memory bank.

The configurable accelerator in accordance with the disclosure can be programmed using control information to implement different operations. The control information can include the following: one or more TXDMA descriptors, one or more RXDMA descriptors, and one or more XE instructions, which may be collectively referred to as “XE commands”. In various embodiments, the XE commands for programming the configurable accelerator can be stored into one or more registers shared by processors and/or the configurable accelerator. In some embodiments, the shared registers can be used to simply store pointers to the XE commands which are stored in the shared data storage memory.

On execution of the XE commands, the configurable accelerator can be directed to initiate, through its TXDMA engine, a DMA transfer request to the RXDMA engine. The DMA transfer request can include RXDMA descriptor information such as a destination address, data transfer length, and/or any other information. The RXDMA engine, upon receiving the DMA transfer request, can generate a request for exclusive write-access to the memory access arbiter associated with the targeted memory bank. Once the exclusive write-access is granted, the RXDMA engine can send the response to the TXDMA engine, indicating that the DMA channel to the targeted bank is open.

After receiving the response from the RXDMA engine, the TXDMA engine can also request and be granted an exclusive read-access to the source bank similar to the RXDMA engine as described above. After the TXDMA engine is granted the exclusive read access, the TXDMA engine can read the source input data from the source memory bank in a streaming manner and in a sequence as set by the XE commands in order for the XE to execute the XE instruction. The source input data stream sequence can be programmed by the XE commands and controlled by the AGUs.

The results of the XE can then be sent to the RXDMA engine. The RXDMA engine can write the results of the XE to the destination memory bank in the sequence as programmed by the RXDMA descriptors. After the entire source input data stream has been processed, the TXDMA engine releases the exclusive read-access to the source memory bank and sends a request to the RXDMA engine to close the DMA channel, thus causing the RXDMA engine to release the exclusive write-access to the destination memory bank.

The use of exclusive read and write accesses to the source and the destination banks as described above allows the configurable accelerator to operate on large sets of streaming data continuously without any pipeline stall. Furthermore, with the configurable accelerator, the AGUs allow XEs to be implemented to handle a wide range of functions including, but not limited to, arithmetic operations involving multiple operands, operations on scalar or vector data, bit manipulation operations, control instructions, etc. Those skilled in the art would also recognize that the configurable accelerate can be programmed to execute a wide range of algorithms by daisy-chaining multiple XE commands. Once programmed, the configurable accelerator can execute the daisy-chained XE commands in the specified sequence. In some embodiments, the configurable accelerator can execute the daisy-chained XE commands in the specified sequence without requiring involvement from the processor until the entire XE command sequence has been executed and the final result of the algorithm is available for the processor.

Additional features, advantages, and embodiments of the invention may be set forth or apparent from consideration of the following detailed description, drawings, and claims. Moreover, it is to be understood that both the foregoing summary of the invention and the following detailed description are exemplary and intended to provide further explanation without limiting the scope of the invention claimed. The detailed description and the specific examples, however, indicate only preferred embodiments of the invention. Various changes and modifications within the spirit and scope of the invention will become apparent to those skilled in the art from this detailed description.

DETAILED DESCRIPTION OF THE INVENTION

In various embodiments, a configurable accelerator is provided. The configurable accelerator can include a TXDMA engine, a RXDMA engine, and one or more execution engines (XEs). In some embodiments, the TXDMA engine can include one or more address generators (AGUs). In some embodiments, the RXDMA engine can also include one or more AGUs. In some embodiments, a shared data storage memory can be connected to a processing unit and the configurable accelerator, for providing programming instructions and/or storing results for the configurable accelerator. The shared data storage memory can include multiple memory banks.

FIG. 1illustrates an exemplary computation architecture100having a configurable accelerator in accordance with the disclosure. As shown, the computation architecture100can include a processing unit group102, a configurable accelerator104, a system bus106, a register group108, shared data storage memory110, and/or any other components. The processor unit group102can include one or more processing units configured to process data stored in the shared data storage memory110. An individual processing unit in the processing unit group102can process data by executing one or more instructions to cause the configurable accelerator to load/store and perform arithmetic functions on the data. The instructions executed by the configurable accelerator104can be stored in a register in the register group108. In certain embodiments, the processing units in the processing unit group102can include one or more general purpose processors configured to execute machine-readable instructions. The instructions for the processor group102can be stored in an instruction memory (not shown). A person of ordinary skill in the art would understand the processing units included in the processing unit group102can include specific purpose processors, micro-controllers, hardware logic, state machine, and/or any other type of processing units.

The configurable accelerator104can be configured to perform functions (including arithmetic functions) on the data stored in the memory banks of shared storage memory110. Different from a traditional hardware accelerator, the configurable accelerator104in accordance with the disclosure can perform different functions in a streaming manner on varying number of operands stored in the memory banks of shared storage memory110. In this sense, the configurable accelerator104in accordance with the disclosure is more flexible than a traditional hardware accelerator which may only perform a specific and preset arithmetic function. Some examples of the configurable accelerator104in accordance with the disclosure will be illustrated inFIG. 2andFIG. 3A.

The system bus106can be configured to connect the one or more processing units in the processing unit group102, the configurable accelerator104, the register(s) in the register group108, the shared data storage memory110, and/or any other components in the computation architecture100. In certain embodiments, the system bus106can be used to transmit information (e.g., control instructions, address information, data) between these components. In one embodiment the system bus106connects the processing units in the processing unit group102and the configurable accelerator104. In an alternate embodiment (not shown), the processing units in the processing group102can be connected directly to the configurable accelerator104, without using a system bus.

The register group108may include one or more registers configured to store instructions. The instructions stored in the register group108, when executed by the configurable accelerator104, can cause the accelerator104to load/process the data stored in the shared data storage memory110, and to store data to the shared storage memory110. The instructions stored in an individual register may include XE commands that can cause the configurable accelerator104to initiate an access request to access the shared data storage memory110, to process data stored in the shared data storage, to store results of the processing to the data storage memory110, and/or to perform any other operations. In one embodiment, the instructions stored in register group108may include an instruction that can cause the configurable accelerator104to load data from a first location to a second location within shared storage memory110. It should be understood that although register group108is illustrated in this example as storing the XE commands, this is not intended to be limiting. In some other embodiments, the XE commands can be stored elsewhere, such as the shared data storage memory110, a dedicated data storage, or any other suitable data storage.

The shared data storage memory110can include multiple individual banks configured to store data to be processed by the one or more processing units in the processing unit group102and the configurable accelerator104. Under the computation architecture100, the configurable accelerator104can be programmed to perform a range of functions on varying number of operands in a streaming manner. By allowing a direct memory access (DMA) of the data stored in the shared data storage memory110, this architecture can speed up performance of the one or more processing units in the processing unit group102. It should be understood, the phrase “streaming manner” or “continuously” used in the context of the configurable accelerator being able to use a DMA access channel without interruption.

The functions that can be performed by the configurable accelerator104can include but not limited to, arithmetic operations involving multiple operands, operations on scalar or vector data, bit manipulation operations, control instructions, etc. Those skilled in the art would also recognize that the configurable accelerator104can be programmed to execute a wide range of algorithms by daisy-chaining multiple XE commands. Once programmed, the configurable accelerator104can execute the daisy-chained XE commands in the specified sequence without requiring involvement from the one or more processors in the processing group102until the entire XE command sequence has been executed.

With the general structure of the computation architecture100in accordance with the disclosure having been described and illustrated, attention is now directed toFIG. 2, where more details in an exemplary implementation of the computation architecture100are illustrated. As shown in this example, the processor group102can include one or more processors202, such as processors202a-n. The individual processors202in the processor group102can execute instructions to cause the configurable accelerator104to process data. The configurable accelerator104, as shown in this example, can include a TXDMA engine204, a RXDMA engine210, an XE206and/or any other components.

The TXDMA engine204and RXDMA engine210can have a given number of channels to use for the DMA transmission, and a given number of request lines. As used herein, a DMA channel may be referred to as a connection between one memory bank of the shared data storage memory110to a different memory bank of the shared data memory110through the XE206, TX DMA engine204, and RXDMA engine210. The DMA channel can be used to transfer information directly between two or more memory banks of the shared data storage memory110. The TXDMA engine204in the configurable accelerator104can be configured to use one or more channels to connect to the RXDMA engine210. In various implementations, during the DMA channel request phase, the TXDMA engine204can be configured to send a DMA transfer request to the RXDMA engine210. The DMA transfer request can include RXDMA descriptor information such as a destination address, data transfer length, and/or any other information. After the channel(s) between the TXDMA engine204and RXDMA engine210is established, data stored in one or more memory banks in shared data storage memory110can be processed in a streaming manner—e.g., loaded by the TXDMA engine204, processed by the XE206and the results stored by the RXDMA engine210. In this way, the configurable accelerator104can operate in continuous fashion to perform a wide range of functions.

It should be understood although one TXDMA engine204, one RXDMA engine210and one XE206are illustrated inFIG. 2as being included in configurable accelerator104, more than one TXDMA engine204, more than one RXDMA engine210, and/or more than one XE206can be included in a configurable accelerator104. For example,FIG. 3Aillustrates one example where the configurable accelerator104can have two XEs206, i.e.,206aand206b. As shown, the XE206bshown in this example can be connected to the RXDMA engine210. In this example, the TXDMA engine204can be configured to send, through a data connect between the TXDMA engine204and RXDMA engine210, XE instructions to the RXDMA engine210. The XE206bcan process data received by the RXDMA engine210continuously. In this way, arithmetic functions with multiple operands can be achieved by the configurable accelerator104.

In some examples, the TXDMA engine204, the RXDMA engine210and the XE206aand206bshown inFIG. 3Acan form an XE block302. In one embodiment, multiple XE blocks302can be daisy chained in the configurable accelerator104. This is illustrated inFIG. 3B. The number of XE blocks302that can be daisy chained in the configurable accelerator104may be a design choice. Typically, the more number of XE blocks302in the configurable accelerator104the more flexibility the configurable accelerator104can be achieved. However, on the other hand, increasing number of blocks302in the configurable accelerator104may increase the cost and the size of the configurable accelerator104.

Referring back toFIG. 2, the TXDMA engine204can be configured to continuously read (load) data from banks in the shared data storage memory110after the DMA channels are open. The data read by the TXDMA engine210can be sent to the XE206for execution. In this way, the XE206can operate on a continuous data stream so that pipeline stalls can be reduced or in some cases even eliminated. In some embodiments, the TXDMA engine204can include one or more an address generators (AGU)216that can be configured to ensure proper address generation to read the required operands (data) for execution by the XE206. In this way, operands (data) are continuously sent to the XE206and the results obtained by the XE206can be streamed to the RXDMA engine210for storage in the memory banks in the shared data storage memory110. In some implementations, the result of the last XE can be temporarily stored in a buffer (not shown) and can be used as an operand for the next data set if necessary.

In some examples, the RXDMA engine210can be connected with an XE206a(such as the one shown inFIG. 3A). In those examples, the RXDMA engine210can be configured to further process the received data with the XE (such as206b) before writing the data to the memory bank location in the shared data storage memory110. In those examples, the XE206bconnected to the RXDMA engine210can be configured to use the received data as its operands, and can be configured to perform further calculations in the performed arithmetic function. In various implementations, the RXDMA engine210can include an address generator, such as the AGU218shown to write the received data to multiple destination addresses in the memory bank as required.

In various implementations, the AGU216and AGU218can be used to determine the next storage memory location from which data can be fetched by the TXDMA engine204or stored by the RXDMA engine210, respectively. In those implementations, the AGU216and AGU218can take the one or more of the following input parameters: start address, end address, address step, address offset, address mode, and/or any other parameters. In some examples, to support various functions required in signal processing applications, the AGU216and AGU218can operate in two different modes: a normal model and a block model.

In the normal mode, the output of the AGU216and AGU218can start at the start address location, and increments by address step every clock cycle until it reaches the end address. In this example, an address is referred to a memory address, and more particularly, to the memory address in the shared data storage memory110. In some applications, it is useful to have an AGU that can generate outputs in “interleaved-fashion” (i.e0,512,1,513,2,514, . . .511,1023). This can allow the XE206to fetch the required operands from multiple address locations.

In the block mode, as in normal node, the AGU216and AGU218can add address step value to the current address to calculate the next address, which is set to 512 for the sequence of 0, 512, 1, 513, 2, 514 . . . 511 1023. However, in the block mode, when the “current address+address step” yields value greater than the end address (1024in this example), the next address can be “wrapped” as shown by the pseudo code below:
If(current_address+Address Step)>=End Address){next_address=((current_address+Address Step)mod End Address)+Address Offset}
Therefore, by way of example, the addresses generated by the AGU described above can be the following:
3rd Address:((512+512)mod 1024)+1=1
4th Address:((1+512)mod 1024)+1=513
5th Address:((513+512)mod 1024)+1=2
. . . until
current_address+Address Offset<=End Address

In summary, by utilizing the two operational modes, the AGU216and/or218can generate various sequences of addresses required for fetching the XE206operands. Having a mixture of AGUs such as216and218in the configurable accelerator104can add flexibility in generating required addresses for the XE206operands. An example implementation800for address generator216and/or218is illustrated inFIG. 8. The number of AGUs that can be included in a TXDMA or RXDMA engine is a design choice and is thus not limited. In general, if an XE is to achieve multiple functions with one of them having a most number of operands, then it may be desired to have this number of AGUs in the TXDMA engine and/or RXDMA engine.

Referring back toFIG. 2, the register group108may include one or more registers, such as registers212a-nas shown in this example. The individual registers in the register group108can include a register that can be used by a processing unit202in the processing unit group102to store an XE command to cause the TXDMA engine204in the configurable accelerator104to transmit data from one or more locations in the shared data storage memory110to another location or other locations in the shared data storage memory110, for example, from one memory block to another. The individual register can be used by a given processor in the processing group102to store an XE command to cause the XE206in the configurable accelerator104to execute the XE command. The configurable accelerator104may be configured to read the XE commands from the register in the register group108and execute the XE commands accordingly. In some embodiments, the shared registers can be used to simply store pointers to the XE commands, while the XE commands are stored in the shared data storage memory110.

The shared data storage memory110may include multiple memory banks, such as the memory banks214a-nas shown in this example. As described, the banks in the shared data storage memory110can store data that to be processed by configurable accelerator104. The TXDMA204and the RXDMA210engines may be configured such that destination location may be in a different bank than the source location. In one embodiment, when data is loaded by the configurable accelerator104from a first memory bank in the shared data storage memory110and processed by the XE206in configurable accelerator104to obtain a result, the result may be stored in a second memory bank that is different from the first memory bank.

As described herein, the configurable accelerator104can be programmed by XE commands to implement different operations. A given XE command can include the following: one or more TXDMA descriptors, one or more RXDMA descriptors, and one or more XE instructions. On execution of the XE commands, the configurable accelerator104can be directed to initiate, through its TXDMA engine204, a DMA transfer request to the RXDMA engine210. The DMA transfer request can include RXDMA descriptor information such as a destination memory address, data transfer length, or any other information. The RXDMA engine210, upon receiving the DMA transfer request, can generate a request for “exclusive write-access” to the arbiter associated with the targeted memory bank. Once the exclusive write-access is granted, the RXDMA engine210can send the response to the TXDMA engine204, indicating that the “DMA channel” to the targeted memory bank is “open”.

After receiving the response from the RXDMA engine210, the TXDMA engine204can also request and be granted a “exclusive read-access” to the source memory bank similar to the RXDMA engine210as described above. After the TXDMA engine204is granted the exclusive read access, the TXDMA engine204can read the source input data from the source memory bank in a continuous streaming manner in a sequence as set by the XE commands in order for the XE206to execute the XE instruction. The source input data stream sequence can be programmed by the XE commands and controlled by the AGUs.

The results of the XE can then be sent to the RXDMA engine210. The RXDMA engine210can write the results of the XE206to the destination memory bank in the sequence as programmed by the RXDMA descriptors. After the entire source input data stream has been processed, the TXDMA engine204releases the exclusive read-access to the source memory bank and sends a request to the RXDMA engine210to “close” the DMA channel, thus causing the RXDMA engine210to release the exclusive write-access to the destination bank.

FIG. 4illustrates one example where the configurable accelerator104is programmed to perform a single operand function. In the embodiment ofFIG. 4, the processing unit group102includes four processors,402a-d. As shown, XE commands412for programming the configurable accelerator104can be stored in the register group408a,408b,408c, and/or408d.

An individual XE command412can include one or more TXDMA descriptors, one or more RXDMA descriptors, and one or more XE instructions. A given TXDMA descriptor can include information such as a source memory address in the shared data storage memory110for loading data, data length, and/or any other information. A given RXDMA descriptor can include information such as a destination memory address in the shared data storage memory110for storing results of the configurable accelerator104, data transfer length, and/or any other information. A given XE instruction can include information instructing the XE406to implement a specific arithmetic function, such as information instructing XE how to process data (operands) read by the TXDMA engine404.

In this example, the configurable accelerator104includes a TXDMA engine404connected to a corresponding XE406a. The TXDMA engine404can load the data continuously (operand) according to the TX descriptor and sends the data to the XE406afor performing the designated operand function on the data in order to generate a result. The XE406acan perform the single operand function according to the XE instruction on the data read by the TXDMA engine404.

The single operand function that can be performed by configurable accelerator104is not limited and can include any suitable function such as shift, etc. In this example, the single operand to be processed by the configurable accelerator104according to the XE instruction is dataset0stored in memory bank0in the shared data storage memory110. As described above, the reading of dataset0by the TXDMA engine404can be continuous after the DMA channels are open. The XE406acan then perform the single operand function on the dataset0according to the XE instruction, which can also read by the configurable accelerator104through the system bus106.

In this example, the embodiment comprises a data connect412between the TXDMA engine404and RXDMA engine410. Data connect412can be any data carrier, connection or channel between the two. As shown, the result obtained by the XE406acan be transmitted back to the TXDMA engine404from XE406a, and then sent to the RXDMA engine410through the data connect412. As shown, the RXDMA engine410can store the result in a memory bank different than the memory bank where the operand (data) is stored. In this example, dataset0is stored in memory bank0and the result is stored in memory bank2.

In a further embodiment (not shown), the processors in the processor group102can be part of a processor sub-system that are inter-connected through one or more network-on-chip routers with other processor group102in a different chip. In those implementations, XE406acan be configured to process data read by TXDMA engine404and the processed data can be transmitted to another processor sub-system. Similarly, on the receiving end, the receiving processor sub-system can perform an arithmetic function on the received data stream via XE406band RXDMA engine410.

In some examples, the configurable accelerator104in accordance with the disclosure can be configured to perform a function involving multiple operands, such as add, subtract, multiply or the like.FIG. 5illustrates one example where different operands that can be processed by the configurable accelerator104in accordance with the disclosure. In this example, the operands are stored in the same memory bank in the shared data storage memory110. As shown in this example, for achieving such a function, the TX descriptor can cause the TXDMA engine404to load dataset0and dataset1into XE406aand perform the first part of multi-operand function. For example, the arithmetic function to be achieved by the configurable accelerator104according to the XE instruction is (dataset0+dataset1)×dataset2, dataset0and dataset1can be first loaded out of bank0by the TXDMA engine404and sent to the XE406afor the addition function.

The result of the addition, i.e., dataset0+dataset1, can then be transmitted from the XE406ato the RXDMA engine410through the TXDMA engine404and the data connect412. The TXDMA engine404can also load the dataset2out of the memory bank0and send it to the RXDMA engine410through the data connect412. After receiving the addition result and dataset1from the TXDMA engine404, the RXDMA engine410can be configured to process the addition result and dataset2using the XE406bthat is connected to the RXDMA engine410. That is the XE406bcan be configured, according to the XE instruction, to multiply the addition result and the dataset2. The result of the XE406bcan then be stored, by the RXDMA engine410into memory bank2.

In some examples, the operands involved in a multi-operand function may not reside in the same bank in the shared data storage110. In those examples, one or more TXDMA descriptors, as well as one or more RXDMA descriptors can be used to load and store all of the operands into a single memory bank and then have the XE410perform the multi-operand arithmetic function on the data in a continuous fashion using DMA to the memory bank. This is illustrated inFIG. 6. As shown inFIG. 6, data or operands for the multi-operand arithmetic function is located in memory banks0and memory bank2. In this example, as shown, after reading the TX descriptor, the TXDMA engine404can be configured to load the datasets0,1, and2out of their respective memory banks, and send them to the RXDMA engine410through the data connect412for storing in a single memory bank, namely memory bank2. As still shown, the RXDMA engine410can be configured to store the datasets0,1and2into the memory bank2in an interleaving fashion. The interleaved data stored in memory bank2can then be loaded out of memory bank2by the TXDMA engine404and sent to XE406afor executing the multi-operand function. The result of this execution can then be sent to the RXDMA engine410via the TXDMA engine404through the data connect412. The result can then be stored by the RXDMA engine210into a memory bank other than memory bank2, in this example, illustrated as storing the result in memory bank3.

The examples of various embodiments provided herein is not intended to be limiting. Those skilled in the art would recognize that an function that can be implemented by XE406according to an XE command can include any customized functions operating more than two operands. In general, the output y(i) of the function ƒ implemented by XE, having m operands from datasets D0 to m-1, can be described as:
y(i)=ƒ(D0(i),D1(i), . . . ,Dm-1(i))for i=0 to N−1, where N=number of elements in a dataset

FIG. 7illustrates an exemplary method700for executing a multi-operand function using the configurable accelerator shown inFIG. 1. It will be evident to those of ordinary skilled in the art that variations of this method can be performed without departing from the teachings of the present disclosure.

At step702, first data can be transmitted from a first memory bank in a shared data storage memory to a destination memory bank, the destination memory bank being different than the first memory bank. In various implementations, operations invovled in step702can be executed by circuitry similar to the TXDMA engine204and RXDMA engine210illustrated and described herein.

At step704, a second data can be transmitted from a second memory bank in a shared data storage memory to the destination. The operations invovled in step704can be executed in a similar way to step702.

At step706, a third data can be transmitted from a memory bank in a shared data storage memory to the destination memory bank. The operations invovled in step706can be executed in a similar way to step702.

At708, the first, second and third data can be stored in the destination bank in an interleaving fashion. An example of interleavingly storing data is illustrated inFIG. 6. It should be understood by a person of ordinary skill in the art that the data could be stored in any fashion that would be dictated by the order required by the function to be performed by the XE.

At step710, the interleaved first, second and third data can be transmitted from the destination bank to an XE as operands in a function to be performed by the XE. The XE involved in710may the same as or substantially similar to the XE206aillustrated and described herein. In various implementations, operations involved in710can be executed by a TX DMA engine the same as or substantially similar to the TXDMA engine204illustrated and described herein.

At step712, a result of the function performed by the XE on the interleaved first, second and third data can be transmitted to a result memory bank in the shared data storage memory. Operations involved in step712can be executed by a RXDMA engine the same as or substantially similar to the RXDMA engine210illustrated and described herein.

Those of skill would further appreciate that the various illustrative logical blocks, configurations, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.