Compact configuration descriptor format for neural network hardware accelerator
The compact configuration descriptor format addresses the challenge of large descriptor sizes in transformer-based DNNs by dividing descriptors into constant and variable parts, facilitating reuse and reducing memory requirements by 75%, thereby improving execution efficiency.
Patent Information
- Application Number
- PCT/CN2024/121289
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-06-27
- Filing Date
- 2024-09-26
- Publication Date
- 2026-01-02
AI Technical Summary
The growing size of neural network models, particularly transformer-based DNNs, leads to significant challenges in compilation and deployment due to the increasing size of configuration descriptors, which consume valuable on-chip memory and increase memory access overhead, making efficient execution difficult.
A compact and lightweight configuration descriptor format is introduced, dividing descriptors into constant and variable parts, allowing for reuse across blocks and within blocks, significantly reducing the size of compiled descriptors and optimizing memory usage.
This approach reduces memory requirements by 75% and processor bandwidth usage, enabling efficient execution of data processing workloads by reusing constant configuration descriptors, thus enhancing performance and resource utilization.
Smart Images

Figure CN2024121289_02012026_PF_FP_ABST
Abstract
Description
COMPACT CONFIGURATION DESCRIPTOR FORMAT FOR NEURAL NETWORK HARDWARE ACCELERATOR
[0001] Cross-reference to Related Applications
[0002] This application claims benefit of priority of International Patent Application Serial No. PCT / CN2024 / 101862, filed June 27, 2024, and entitled “WORKLOAD DESCRIPTOR FORMAT, ” the disclosure of which is considered part of (and is incorporated by reference herein) the disclosure of the present application.Background
[0003] Deep neural networks (DNNs) are used extensively for a variety of artificial intelligence applications ranging from computer vision to speech recognition and natural language processing due to their ability to achieve high accuracy. However, the high accuracy comes at the expense of significant computation cost. DNNs have extremely high computing demands as there can be a large number of operations as well as a large amount of data to read and write.Brief Description of the Drawings
[0004] Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.
[0005] FIG. 1 illustrates an exemplary full configuration descriptor format, according to some embodiments of the disclosure.
[0006] FIG. 2 illustrates a processing graph of a neural network, according to some embodiments of the disclosure.
[0007] FIG. 3 illustrates blocks in a decoder of a transformer-based neural network, according to some embodiments of the disclosure.
[0008] FIG. 4 illustrates layers in a mixture of experts transformer-based neural network, according to some embodiments of the disclosure.
[0009] FIG. 5 illustrates reuse across blocks, according to some embodiments of the disclosure.
[0010] FIG. 6 illustrates reuse within a block, according to some embodiments of the disclosure.
[0011] FIG. 7 illustrates reuse within mixture of experts, according to some embodiments of the disclosure.
[0012] FIG. 8 illustrates a constant configuration descriptor using a compact format, according to some embodiments of the disclosure.
[0013] FIG. 9 illustrates a variable configuration descriptor using a compact format, according to some embodiments of the disclosure.
[0014] FIGS. 10A-C illustrate memory usage when using a full configuration descriptor format versus using a compact configuration descriptor format, according to some embodiments of the disclosure.
[0015] FIG. 11 illustrates a DNN system, according to some embodiments of the disclosure.
[0016] FIG. 12 illustrates a processing engine, according to some embodiments of the disclosure.
[0017] FIG. 13 illustrates a post-processing engine, according to some embodiments of the disclosure.
[0018] FIG. 14 illustrates a variable size descriptor format, according to some embodiments of the disclosure.
[0019] FIG. 15 illustrates a state machine, according to some embodiments of the disclosure.
[0020] FIG. 16 illustrates a DNN module, according to some embodiments of the disclosure.
[0021] FIG. 17 illustrates a compiler, according to some embodiments of the disclosure.
[0022] FIG. 18 illustrates memory accesses to fetch a constant configuration descriptor, according to some embodiments of the disclosure.
[0023] FIG. 19 is a flowchart showing a method for generating configuration descriptors, according to some embodiments of the disclosure.
[0024] FIG. 20 is a flowchart showing a method for fetching configuration descriptors, according to some embodiments of the disclosure.
[0025] FIG. 21 is a block diagram of an exemplary computing device, according to some embodiments of the disclosure.Detailed Description
[0026] Overview
[0027] DNNs are used in a variety of applications in the domains such as computer vision, speech recognition, image generation, video generation, etc. DNNs can achieve high accuracy, and in some cases, perform at superhuman-level accuracy. DNNs have interconnected neurons (or operations) that process data, and the layered structure of neural networks enable complex machine learning tasks to be performed. Neural network hardware accelerators with specialized circuitry can perform the operations in an efficient manner.
[0028] In some neural network hardware accelerators, multiple data processing units (DPUs) can be provided in the neural network hardware accelerator to enable fast, specialized, and parallel data processing. In a DPU, a data processing pipeline may be implemented to include a processing engine and a post-processing engine (PPE) . The processing engine may be tasked to perform neural network operations such as matrix multiplications and convolutions, while the PPE following the processing engine may be tasked to apply neural network operations such as scaling, adding a bias, and applying an activation function. A data processing workload can be scheduled and initiated onto the DPU to be executed by the data processing pipeline. To configure the DPU to perform a data processing workload, a configuration descriptor can be used and loaded onto the DPU to cause the DPU to perform one or more neural network operations of the data processing workload. The configuration descriptor can include instructions and / or register configurations that would configure the hardware circuitry, including registers, of the data processing pipeline to perform the one or more neural network operations on input data and produce output data. In some contexts, a configuration descriptor may be referred to as a workload descriptor.
[0029] Prior to deployment of a neural network model onto a neural network hardware accelerator, a compiler can receive a neural network definition that includes neural network operations associated with a neural network model. Based on the neural network definition, the compiler can identify one or more data processing workloads to be executed by the DPUs of the neural network hardware accelerator. The compiler can produce a processing graph having the one or more data processing workloads. Based on the one or more data processing workloads, the compiler can produce configuration descriptors that can be used to configure the data processing units of the neural network hardware accelerator to carry out the one or more data processing workloads. Data processing units of a neural network hardware accelerator may be configured to perform neural network operations of the neural network model using configuration descriptors generated by the compiler.
[0030] DNNs have grown, in the era of using DNNs such as transformer-based DNNs to implement large language models (LLMs) , from having millions of parameters to billions of parameters. Larger models have caused 1000X growth in computing demand in just a few years, as the community develop larger models for higher accuracy. LLMs are a type of DNN that has been used for processing and generating data to support a variety of artificial intelligence (AI) tasks. LLMs leverage complex neural networks, typically based on transformer architectures, to capture intricate patterns in language, enabling them to perform tasks such as text completion, question answering, translation, and even creative writing. The scale of these models, often comprising billions of parameters, allows them to exhibit remarkable linguistic capabilities and a degree of general knowledge that was previously unattainable in machine learning systems. Transformer architectures can also be used for other modalities including computer vision and audio.
[0031] Growing sizes of neural network models can mean that the compiled configuration descriptors can become larger in size as well. Compile time can be longer, and storage overhead also increases. Therefore, the constantly growing model size brings technical challenges to model compilation and deployment. For a 7-billion parameter large language model, a compiler can identify ~200,000 data processing workloads and produce compiled configuration descriptors having storage size of 96 megabytes (MB) . The on-chip fast working memory of a DPU, e.g., a static random access memory (SRAM) , may have just ~1.5-2 MB of capacity. 96 MBs of compiled configuration descriptors is 48X more than the capacity of the on-chip memory, which is mainly intended to store the activation and weight data for matrix multiplications and convolutions being performed by the processing engine. Therefore, the size of the compiled configuration descriptors, if not managed properly, can use up valuable capacity of the on-chip memory and / or increase memory access overhead, which may lead to slower execution of the data processing workloads on the DPUs.
[0032] One practice is to use a configuration descriptor format that has (all) register configurations in a configuration descriptor. But the problem arises when the configuration descriptor becomes a couple of hundreds of bytes long. This configuration descriptor may not pose to be a significant problem with smaller, vision-based DNNs since the configuration descriptor is still relatively small compared to the convolution weights. However, with an increasing number of transformer-based DNNs, this problem is becoming more severe.
[0033] It can be beneficial to equip systems (software and hardware) with the ability to perform local LLM inference efficiently. As artificial intelligence-based applications and workloads spread across various platforms, from the cloud to edge computing and client devices, the need for optimized performance becomes increasingly important. Efficient compilation and deployment of LLMs on on-device neural network hardware accelerators can address some of these concerns.
[0034] To address the problem of large configuration descriptors in LLM compilation, the described embodiments reduce overhead by introducing a compact and lightweight configuration descriptor format. The compact and lightweight configuration descriptor format can include a constant part or portion, and a variable part or portion. The constant part or portion is referred to herein as the constant configuration descriptor. The variable part or portion is referred to herein as the variable configuration descriptor. The compact configuration descriptor format can divide the full configuration descriptor into two parts: constant fields and variable fields. Remarkably, the length of this compact configuration descriptor is just one-tenth that of the full configuration descriptor. Furthermore, the design facilitates the sharing and reusing of constant configuration descriptors among repeated operations, enhancing efficiency. The compact configuration descriptor format facilitates reuse across blocks, within blocks, and within a mixture of experts for a transformer-based model.
[0035] The compiler is improved to include the ability to group data processing workloads in the processing graph having a common (same) operation together. Grouping workloads with a common operation allows for the reuse of a constant configuration descriptor. The compiler can produce the constant configuration descriptor and respective variable configuration descriptors for the grouped data processing workloads. The compact configuration descriptor format can dramatically reduce the size of the compiled configuration descriptors. Consider a 7-billion parameters LLM model with a sequence length of 512 as an example: using the full configuration descriptor format would lead to reserving 96 MB for the compiled configuration descriptors. With the compact and lightweight configuration descriptor format, the space requirement reduces to a mere 2.5 MB, which is roughly a 40X reduction over the original size.
[0036] A data processing unit of a neural network hardware accelerator is improved to include a hardware (HW) descriptor fetch state machine that can exploit the reuse through compiler generated tag verification as part of a two-level indirection in the descriptor storage. If the tag for the constant configuration descriptor for the next data processing workload matches one that was already loaded onto memory, fetching of the constant configuration descriptor is skipped and just the variable configuration descriptor is loaded onto the memory. The constant configuration descriptor already loaded in the memory is reused to execute the next data processing workload. In an experiment, this technique demonstrated a reduction in memory requirements by 75%, because execution of subsequent data processing workloads only needed to account for the overhead of their variable configuration descriptors. This technique saves processor bandwidth and on-chip SRAM storage between the execution of data processing workloads that can be exploited for descriptor-level reuse.
[0037] Configuration descriptor overhead
[0038] DPUs of a neural network hardware accelerator have highly specialized hardware that can execute data processing workloads for a neural network very efficiently. In some implementations, a DPU’s data processing pipeline can execute a data processing workload involving a compute operation followed by a post-processing operation such as applying an activation function. To initiate the DPU’s data processing pipeline, a configuration descriptor having configuration information for the processing engine to perform the compute operation and configuration information for the PPE to apply the activation function can be loaded onto the DPU. To execute the data processing workload, the data processing pipeline of the DPU can cause input data of the data processing workload to be passed to the processing engine, and the processing engine can generate output data by performing the specified compute operation. The output data generated by the processing engine is then passed to the PPE (the next operation in the data processing pipeline) , and the PPE can generate output data by applying the specified activation function. The output data generated by the PPE is passed onwards as the output data of the data processing workload. The data processing pipeline of a DPU that can execute data processing workloads is described further in FIGS. 11-13.
[0039] FIG. 1 illustrates an exemplary full configuration descriptor format, according to some embodiments of the disclosure. The configuration descriptor format may include all register configurations in the configuration descriptor, such as memory addresses and offsets for retrieving and / or writing data (e.g., activation tensor, weight tensor, and output tensors) , configurations for the processing engine, and configurations for the post-processing engine of a DPU. A configuration descriptor may include one or more fields for the register configurations. Different fields may be dedicated for specifying different configurations of various neural network operations. Register configurations may configure a DPU (e.g., the processing engine and / or the post-processing engine) to perform one or more operations and specify configurations for the one or more operations. Register configurations may configure a DPU to fetch data from one or more memory locations and / or fetch data in a certain manner. Register configurations may configure a DPU to write data to one or more memory locations and / or write data in a certain manner. Register configurations may include look up table values for a software programmable look up table in a post-processing engine of a DPU. A configuration descriptor for a data processing workload using the full configuration descriptor format can be a couple or few hundreds of bytes long (e.g., 500 bytes) . A configuration descriptor can be large due to the DPU being able to support a variety of operations and configurations for the operations.
[0040] FIG. 2 illustrates a processing graph of a neural network, according to some embodiments of the disclosure. In particular, FIG. 2 illustrates a feed-forward network (FFN) subgraph of a 7-billion parameter LLM. The subgraph includes MatMul <4096, 11008> and MatMul <11008, 4096>. MatMul refers to matrix multiplication. Matrix multiplication is one component in the architecture of LLMs, particularly within the attention mechanisms and feed-forward neural networks of transformer-based models. In these models, information is represented as matrices and vectors, and MatMul operations are used to transform and combine this information throughout the network. Specifically, in the attention mechanism, MatMul is used to compute attention scores by multiplying query matrices with key matrices. These scores determine how much focus or "attention" should be given to different parts of the input sequence. Another MatMul operation then combines these attention scores with value matrices to produce context-aware representations. In the feed-forward network layers such as the one illustrated in FIG. 2, MatMul operations project the input into a higher-dimensional space and then back to the original dimensionality, allowing the model to capture complex relationships in the data. The efficiency of MatMul operations on modern processors enables the training and deployment of large-scale language models. However, as model sizes grow, optimizing these operations becomes increasingly important to manage computational complexity and resource requirements.
[0041] To fit into the memory of each DPU, a compiler may split / unroll the MatMul operation seen in FIG. 2 further into smaller pieces (e.g., smaller data processing workloads) . This can lead to many more configuration descriptors being generated as a result. For example, given a 7-billion parameter LLM, a compiler can generate 4, 730 configuration descriptors in which each descriptor’s length is 500 bytes. Since the 7-billion parameter LLM has 32 repeat blocks, the total compiled descriptor size can be 4, 730 *500 bytes *32 = 75 MB.
[0042] In transformer-based DNNs, a decoder may have several repeated blocks that have identical operations but with different activation and weight data. FIG. 3 illustrates blocks in a decoder of a transformer-based neural network, according to some embodiments of the disclosure. In one transformer-based neural network, the decoder may have 32 transformer blocks. Each block has MatMuls for Query, Key, Value along with SoftMax and FFN modules. The shapes of activation and weight tensor are consistent across the 32 blocks.
[0043] This pattern can pose issues with domain-specific accelerators (DSAs) , such as neural network hardware accelerators, designed in the era of convolution-dominant neural network models. For a configuration descriptor that configures a DPU to perform matrix multiplication, the load module of the DPU is configured to load from a specified address in the on-chip memory (e.g., SRAM) and store outputs to a target address in the on-chip memory. Also, the post-processing unit is configured by the configuration descriptor to apply an activation function and cast operations like transpose. If the neural network hardware accelerator is well-designed for compression (e.g., low-bit data type) , the quantization and sparsity configuration settings are also configured by the configuration descriptor. This makes the design of configuration descriptor format a challenge.
[0044] For smaller models without this pattern, using a full configuration descriptor format as illustrated in FIG. 1 was acceptable because the configuration descriptor was relatively small compared to the convolution weights. However, for larger transformer-based neural networks, a large number of configuration descriptors are produced by the compiler due to the structure of the FFN layers as illustrated in FIG. 2 and presence of repeat blocks in the decoder architecture as illustrated in FIG. 3. The size of the compiled configuration descriptors become significantly larger relative to the convolution weights.
[0045] FIG. 4 illustrates layers in a mixture of experts (MOE) transformer-based neural network, according to some embodiments of the disclosure. MOE, which is an emerging model of transformer-based networks, can encounter the issue of the descriptor being too big, or that the size of the compiled configuration descriptors is relatively large compared to the convolution weights. MOE transformer-based neural networks can exacerbate the issue of large configuration descriptors. MOE models have a higher number of parameters to achieve the same model quality as their dense counterparts. Specifically, an exemplary MOE model may include self-attention 402, add and normalize 404, switching FFN layer 406, and add and normalize 420. Rather than using one FFN, the MOE model has multiple FFNs included in switching FFN layer 406. As illustrated switching FFN layer 406 includes FFN 412, FFN 414, FFN 416, and FFN 418. The multiple FFNs serve as multiple experts. Each expert can include a full FFN similar to a traditional transformer-based neural network. Switching FFN layer 406 further includes router 410, which includes a lightweight neural network to decide which FFN should process a token in the input sequence. For each token, router 410 may determine a probability distribution over the FFNs in switching FFN layer 406. Based on the distribution, router 410 may select a top-k expert (e.g., k= 1 or 2) , and the input token is then passed on to the selected top-k expert for further processing. Because of the architecture of switching FFN layer 406, an MOE transformer-based neural network can require more memory for training and inference even though MOE models require less compute. Lastly, a critical consideration is that MOE models’ large size makes inference difficult and costly. The large size makes the compiler process more weights and generates a larger number of data processing workloads and thus configuration descriptors. As discussed above, a configuration descriptor might consume a few hundred bytes. Therefore, the configuration descriptor overhead for MOE transformer-based neural networks is significant. The cost to compile an MOE model having 7-billion parameters is similar to compiling a 68-billion parameter LLM even though the MOE model’s active parameters size is ~12-billion. For a 8x7-billion parameter LLM with 32 repeat blocks in the decoder, the total compiled descriptor size can be 8 *4, 730 *500 bytes *32 = 600 MB.
[0046] Leveraging reuse patterns
[0047] Referring back to FIGS. 2-4, transformer-based neural networks, even MOE transformer-based neural networks, exhibit repeat patterns having repeated operations, which can be leveraged or exploited in a solution that can significantly reduce the overhead of generation and loading of configuration descriptors. A compact configuration descriptor format divides a configuration descriptor into a constant part and a variable part. A more compact configuration descriptor can be generated for repeated operations. The same constant configuration descriptor can be reused across the repeated operations, and (small) variable configuration descriptors can be generated for the repeated operations. The repeat patterns may be present across different levels of hierarchy, which means that the repeat patterns can enable constant configuration descriptor reuse across the different levels of hierarchies. FIGS. 5-7 illustrate three types of configuration descriptor reuse across different levels of hierarchy.
[0048] FIG. 5 illustrates reuse across blocks, according to some embodiments of the disclosure. The MatMul (Q, K, V) and FFN operations in Block0 have identical configurations (e.g., shapes, data types) as those operations in the following 31 Blocks. When configuration descriptors for these common operations (having the same configurations) across blocks use the compact configuration descriptor format, the size of compiled configuration descriptors can be reduced to 1 / 32 of compiled configuration descriptors that follow the full configuration descriptor.
[0049] FIG. 6 illustrates reuse within a block, according to some embodiments of the disclosure. Within the same block, MatMul for Query, Key, Value has the same parameters and therefore same configuration space. Therefore, the common operations (having the same configurations) within a block can share the same constant configuration descriptor.
[0050] FIG. 7 illustrates reuse within mixture of experts, according to some embodiments of the disclosure. The switching FFN layer has multiple experts, or FFNs. The shape of the operations in the experts are the same (e.g., MatMuls of the experts share the same configurations) . When processing an input token, just one or two experts may be active. Therefore, the common operations across the experts can share the same constant configuration descriptor.
[0051] Compact configuration descriptor format
[0052] As seen in FIGS. 5-7, one operation that is often repeated with the same configurations is the MatMul operation. One insight applied when designing the compact configuration descriptor format is that MatMul can be represented with far fewer configuration fields in the configuration descriptor. For example, the halo region configuration and operation configurations like stride / kernel size (present in the exemplary full configuration descriptor depicted in FIG. 1) are not required for the MatMul operation. The practice of maintaining all register configurations in one workload descriptor is certainly not ideal for such cases. This amount of space occupied by these unused fields can be wasted. In another example, when two MatMul operations share some of the same configurations, the corresponding portions of the configuration descriptor probably do not need to be duplicated or repeated in multiple configuration descriptors. The compact configuration descriptor thus separates a configuration descriptor into a constant configuration descriptor and a variable configuration descriptor and aims to make a configuration descriptor more concise by removing some of the fields (and using only the essential fields) . In some embodiments, the variable configuration descriptor measures merely 1 / 10 of the length of a full configuration descriptor (e.g., such as the full configuration descriptor depicted in FIG. 1) . As a result, the compact configuration descriptor format can offer a more efficient alternative.
[0053] A compact and lightweight configuration descriptor format has one or more advantages. Firstly, configuration descriptors that follow the compact format are much more compact. Other configuration descriptors following the full configuration descriptor format, such as the format illustrated in FIG. 1, are verbose, averaging around 500 bytes in size. The full configuration descriptor format as illustrated in FIG. 1 encompasses an extensive array of potential configurations including fields like opcode, operation-specific parameters, halo region setting, configuration for load module, configuration for output module, configuration for processing engine, and configuration for post-processing engine, etc. In contrast, the compact configuration descriptor format includes fields which are specific for the operation, e.g., fields specific to and / or essential to configuring the DPU to perform the MatMul operation (only) . Secondly, the compact configuration descriptor format delineates between constant and variable fields, and the configuration descriptor is broken into a constant configuration descriptor and a variable configuration descriptor. For subsequent repeated operations, only the variable configuration descriptor is compiled. A DPU has appropriate logic to process the variable configuration descriptor of the data processing workload and locate the (reused) constant configuration descriptor for the data processing workload. The constant and variable configuration descriptors can be put back together by the DPU (where the constant configuration descriptor is reused) to configure the DPU to execute the data processing workload.
[0054] FIGS. 8-9 illustrate a constant configuration descriptor for the MatMul operation and a variable configuration descriptor for the MatMul operation or MatMul as part of a convolution operation. FIG. 8 illustrates a constant configuration descriptor using a compact configuration descriptor format, according to some embodiments of the disclosure. The constant configuration descriptor includes one or more configurations, such as: an activation tensor shape ( “ACT_SHAPE” ) , a weight tensor shape ( “WEIGHT_SHAPE” ) , an output tensor shape ( “OUT_SHAPE” ) , a data type ( “Data_Type” ) , a padding configuration ( “Padding” ) , a configuration for a processing engine working mode ( “PE_CFG” ) , a configuration for a post-processing engine working mode ( “PPE_CFG_SCALE” , “PPE_CFG_BIAS” , “PPE_CFG_CLAMP” ) , a configuration for a load module ( “IDU_CFG_1” , “IDU_CFG_2” , “IDU_CFG_3” ) , and a configuration for an output module ( “ODU_CFG_1” , “ODU_CFG_2” , “ODU_CFG_3” ) . An activation tensor shape configuration may specify one or more of: a height ( “H” ) of an activation tensor, a width ( “W” ) of the activation tensor, and a number of channels ( “C” ) of the activation tensor. A weight tensor shape configuration may specify one or more of: a kernel size ( “K” ) of the weight tensor, a kernel height ( “Kh” ) of the weight tensor, and a kernel height ( “Kh” ) of the weight tensor. An output tensor shape configuration may specify one or more of: a height ( “H” ) of an output tensor, a width ( “W” ) of the output tensor, and a number of feature maps ( “K” ) of the output tensor. A data type configuration may specify the number of bits and data type (e.g., integer, floating-point, etc. ) used to represent one or more of the activation tensor, the weight tensor, and the output tensor. A padding configuration may specify the amount of padding at one or more of: top, left, bottom, and right sides. A configuration for a processing engine working mode may specify layer dimensions, which may include an indication of whether the compute operations are to be performed depth-wise. A configuration for a post-processing engine working mode may specify one or more post-processing operations, such as applying an activation function, applying a bias, clamping, scaling, etc. A configuration for a load module may specify how to read activation tensor data from a local memory (e.g., SRAM) , including specifying one or more of: sparsity configuration, stride, program counter, address spacing / jump / step configuration, etc. A configuration for an output module may specify how to write output tensor data to the local memory.
[0055] FIG. 9 illustrates a variable configuration descriptor using a compact configuration descriptor format, according to some embodiments of the disclosure. The variable configuration descriptor includes comprises a memory pointer referring to a memory location of the constant configuration descriptor ( “CONSTANT_WR_PTR” ) , and one or more of: an address of an activation tensor ( “ACT_ADDRESS_PTR” ) , an address of a weight tensor ( “WEIGHT_ADDRESS_PTR” ) , and an address of an output tensor ( “OUTPUT_ADDRESS_PTR) . The memory location of the constant configuration descriptor may specify information pointing to where the constant configuration descriptor is stored in a memory. The address of an activation tensor may specify information pointing to where the activation tensor is stored in a memory (e.g., SRAM) , or where to read the activation tensor from the memory. The address of a weight tensor may specify information pointing to where the weight tensor is stored in a memory (e.g., SRAM) , or where to read the weight tensor from the memory. The address of an output tensor may specify information pointing to where the output tensor is to be stored in a memory (e.g., SRAM) , or where to write the output tensor to the memory.
[0056] FIGS. 8-9 illustrate fields for the constant configuration descriptor and the variable configuration descriptor respectively. The constant configuration descriptor and the variable configuration descriptor together specify a MatMul operation that can be performed by a DPU of a neural network hardware accelerator.
[0057] In FIG. 8, the constant configuration descriptor is concise and occupies approximately 40 bytes. The constant configuration descriptor may include one or more fields that instruct the one or more data processing units to execute a neural network operation according to one or more configurations. The one or more fields may include register configurations for the one or more data processing units, e.g., configuring a processing engine and / or a post-processing engine to execute one or more neural network operations. The one or more fields in the constant configuration descriptor may include one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.
[0058] In FIG. 9, the variable configuration descriptor is even more compact, at rough 12 bytes. The variable configuration descriptor may include one or more fields that instruct the one or more data processing units to execute a neural network operation according to one or more configurations. The one or more fields may include one or more memory pointers (which instructs or configures a data processing unit to fetch and / or write to certain memory locations) . The one or more memory pointers can include one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor. Moreover, the one or more fields may include a field specifying where to locate the constant configuration descriptor in memory. The one or more memory pointers in the variable configuration descriptor can include a memory pointer referring to a memory location of the constant configuration descriptor. This efficient allocation of space for the variable configuration descriptor means that a substantial 80%of the fields are shared across various data processing workloads, promoting a high degree of reusability. Conversely, only about 25%of the fields in a configuration descriptor are dedicated to accommodating the nuances of each unique variant of a data processing workload or operation, ensuring that the configuration descriptor remains as lightweight as possible without sacrificing specificity.
[0059] Once the constant configuration descriptor and the variable configuration descriptor of a data processing workload are loaded onto one or more memories accessible by a data processing unit (e.g., by a hardware state machine, or hardware logic) , the data processing unit has necessary register configurations to be configured to execute the data processing workload. The data processing unit can execute the data processing workload using the constant configuration descriptor and the variable configuration descriptor that have been loaded onto the memory, e.g., by loading the register configurations in the constant configuration descriptor and the variable configuration descriptor onto the register files of the data processing unit. The values in the register files configures the circuitry in the data processing unit (e.g., a processing engine and / or a post-processing engine) to execute one or more neural network operations in the data processing workload.
[0060] Reducing memory usage of configuration descriptors with block-level reuse
[0061] To harness the full potential of the compact configuration descriptor format having a constant configuration descriptor and a variable configuration descriptor, the compiler is improved to detect the reuse patterns present within the processing graph determined based on a neural network definition. Details relating to the compiler are further described with FIGS. 16-17. The compact configuration descriptor format having constant and variable fields is designed to facilitate the sharing and reuse of workloads and instructions across various levels of hierarchy, thereby optimizing resource utilization and enhancing performance.
[0062] Consider the reuse across blocks scenario (as illustrated in FIG. 5) . Two identical MatMuls are situated within Block0 and Block1. In the absence of any reuse mechanism, the memory allocation for these two MatMuls would amount to a total of 100 bytes. However, with the implementation of the compact configuration descriptor format, which includes using the 40-byte constant configuration descriptor encapsulating the invariant aspects of the workloads, the constant configuration descriptor can be efficiently saved and utilized for both instances. Reusing the constant configuration descriptor not only reduces the memory footprint but also streamlines the computational process, as the shared / reused constant configuration descriptor does not need to be redundantly fetched and stored. Memory usage without reuse may equal to (Constant_Size + Variable_Size) *N. Memory usage with reuse may equal to Constant_Size + (Variable_Size*N) . Constant_Size represents the length (in bytes) of the constant configuration descriptor. Variable_Size represents the length (in bytes) of the variable configuration descriptor. N represents the number of data processing workloads that have a common operation that can be encapsulated by the constant configuration descriptor.
[0063] FIGS. 10A-C illustrate memory usage when using a full configuration descriptor format versus using a compact configuration descriptor format, according to some embodiments of the disclosure. FIG. 10A illustrates memory usage of configuration descriptors for two MatMul operations across blocks (Block0. MatMul and Block1. MatMul) without reuse. FIG. 10B shows that the configuration descriptors can each have a constant part and a variable part. FIG. 10C shows reuse of the constant part for both MatMul operations (Block0. MatMul and Block1. MatMul) , and the memory footprint is reduced significantly.
[0064] The following table illustrates that the memory usage of configuration descriptors for performing BLOCK1. MatMul is dramatically reduced when constant configuration descriptors (from BLOCK0. MatMul) are reused.
[0065] For the 7-billion parameter LLM, the reuse factor may equal to 32 (number of blocks) *3 (repeat MatMul in single block) = 96. For an MOE version of the 7-billion parameter LLM (an 8x7B parameter model) , the reuse factor may equal to = 32 (number of blocks) *3 (repeat MatMul in single block) *8 (number of experts) = 768.
[0066] Implementing DNNs on processors or neural network hardware accelerators
[0067] The significant improvements in DNN model size and accuracy coupled with the rapid increase in computing power of execution platforms have led to the adoption of DNN applications even within resource constrained mobile and edge devices that have limited power availability. DNN models may be executed, e.g., for training or inference, by DNN accelerators, or referred to herein as neural network hardware accelerators. A DNN accelerator may be or include one or more data processing units, or DPUs. A DPU may also be referred to as a compute block or compute tile. A DPU has highly specialized hardware circuitry to perform neural network operations. A DPU may include one or more processing engines that can carry out neural network operations or compute operations. A processing engine may include one or more processing cells to perform arithmetic operations associated with neural network operations, such as multiplication and multiplication and accumulate. A DPU may include one or more PPEs that can carry out neural network operations such as scaling, adding a bias, and applying an activation function.
[0068] FIG. 11 illustrates DNN system 1100, according to some embodiments of the disclosure. The whole DNN system 1100 or a part of DNN system 1100 may be implemented in one or more computing devices, such as the computing device 2100 in FIG. 21. DNN system 1100 can generate and execute DNNs, such as transformer-based neural networks, convolutional neural networks, and so on. As shown in FIG. 11, DNN system 1100 includes DNN module 1101 and DNN accelerator 1102. In other embodiments, alternative configurations, different or additional components may be included in DNN system 1100. For instance, DNN system 1100 may include multiple DNN modules or multiple DNN accelerators. Further, functionality attributed to a component of the DNN system 1100 may be accomplished by a different component included in the DNN system 1100 or a different system. In some embodiments, DNN module 1101 and DNN accelerator 1102 may include or be implemented by different types of processing units. In an example, the DNN module 1101 may be implemented by one or more central processing units (CPUs) . The DNN accelerator 1102 may also be referred to as a neural network hardware accelerator, a neural processing unit, AI accelerator, or AI processor. The DNN module 1101 and DNN accelerator 1102 may be implemented in the same chip or as separate chips.
[0069] DNN module 1101 facilitates generation and deployment of DNNs. In some embodiments, the DNN module 1101 may generate and train DNNs. For instance, the DNN module 1101 can define the layered architecture of a DNN. The DNN module 1101 can also determine the internal parameters of the DNN through a DNN training process. The DNN module 1101 may also determine one or more hyperparameters that define how the DNN is trained. An example hyperparameter is a sparsity ratio that defines the sparsity level of one or more deep learning tensors for the DNN.
[0070] DNN module 1101 may compress DNNs, e.g., during or after training. In some embodiments, DNN module 1101 may prune weights in one or more layers of a DNN by changing nonzero valued weight to zeros. DNN module 1101 may prune weights based on a target weight sparsity ratio. A weight sparsity ratio may be the ratio of the number of zero-valued weights to the total number of weights. In an example where the DNN module 1101 prunes weight during DNN training, the DNN module 1101 may prune weight of a layer to achieve a target sparsity ratio after one or more epochs. DNN module 1101 may prevent the pruned weights from changing values during the rest of the training process. Alternatively, DNN module 1101 may allow the pruned weights to change values so that a pruned, zero-valued weight may have a nonzero value after further training. DNN module 1101 may prune weights of the layer again after one or more additional epochs.
[0071] DNN module 1101 may deploy trained, compressed, or validated DNNs for use in deep learning applications. In some embodiments, DNN module 1101 may distribute trained, compressed, or validated DNNs to devices or systems which may use the DNNs to perform tasks (e.g., image classification, motion planning, etc. ) for which the DNNs were trained. In other embodiments, DNN module 1101 may facilitate deployment of the DNNs using the DNN accelerator 1102. For instance, DNN module 1101 may receive data from a device or system coupled with DNN system 1100 and input the received data (or data generated by DNN module 1101, e.g., based on the received data) into a DNN. DNN module 1101 may compile instructions executable by DNN accelerator 1102 to perform operations of a DNN in accordance with a model definition of the DNN. DNN module 1101 may generate instructions (e.g., configuration descriptors, low-level machine instructions, etc. ) that control the operation of the DNN accelerator 1102 during the DNN execution. The instructions may correspond to one or more data processing workloads sent from DNN module 1101 to DNN accelerator 1102, where the one or more data processing workloads are to be executed by DNN accelerator 1102. DNN module 1101 may receive an output of the DNN from the DNN accelerator 1102. DNN module 1101 may transmit the output of the DNN (or a result of processing the output of the DNN by DNN module 1101) to the device or system. In some embodiments, DNN module 1101 may control execution processes of trained, compressed, or validated DNNs. DNN module 1101 may function as a compiler for DNNs to be deployed onto and executed by DNN accelerator 1102. DNN module 1101 may perform compilation of DNNs and generate configuration descriptors and / or low-level machine instructions, based on which the DNNs may be executed. Certain aspects of the DNN module 1101 are described and illustrated in FIGS. 16 and 17.
[0072] DNN accelerator 1102 executes DNNs provided by DNN module 1101. For instance, DNN accelerator 1102 can execute a DNN by running deep learning operations in the DNN. The process of carrying out a deep learning operation is also referred to as a process of executing the deep learning operation or a process of performing the deep learning operation. The execution of the DNN may be for training the DNN or for using the DNN to perform AI and / or inference tasks.
[0073] As shown in FIG. 11, DNN accelerator 1102 includes memory 1110, direct memory access (DMA) engine 1120, and data processing units 1130 (individually referred to as “data processing unit 1130” ) . In other embodiments, alternative configurations, different or additional components may be included in DNN accelerator 1102. For example, DNN accelerator 1102 may include more than one memory 1110 or DMA engine 1120. As another example, DNN accelerator 1102 may include a single data processing unit 1130. Further, functionality attributed to a component of DNN accelerator 1102 may be accomplished by a different component included in DNN accelerator 1102 or by a different system. A component of DNN accelerator 1102 may be implemented in hardware, software, firmware, or some combination thereof.
[0074] Memory 1110 stores data associated with deep learning operations performed by DNN accelerator 1102. Example deep learning operations include convolutions (also referred to as “convolutional operations” ) , layer normalization operations, SoftMax operations, matrix multiplication operations, pooling operations, elementwise operations, activation functions, other types of deep learning operations, or some combination thereof.
[0075] In some embodiments, memory 1110 may store data to be used by the data processing units 1130 for DNN execution. memory 1110 may store weights, such as weights of convolutional layers, which are determined by training DNNs. Memory 1110 may further store inputs to DNN layers and / or outputs of DNN layers, such as data generated by the data processing units 1130 from performing deep learning operations in DNNs.
[0076] Memory 1110 may store instructions (e.g., configuration descriptors, low-level machine instructions, etc. ) executable by DNN accelerator 1102, such as instructions executable by data processing unit 1130. Memory 1110 may be a main memory of DNN accelerator 1102. In some embodiments, memory 1110 includes one or more dynamic random access memories (DRAMs) . In some embodiments, cache 1112 may serve as a cache for memory 1110. Cache 1112 may include one or more SRAMs. Cache 1112 may offer faster data / memory accesses than memory 1110. Cache 1112 may store data that is frequently accessed. Capacity of cache 1112 is smaller than the capacity of memory 1110.
[0077] DMA engine 1120 facilitates data transfer between memory 1110 and local memories 1140 of the data processing units 1130. For example, DMA engine 1120 can read data from memory 1110 and write data into local memory 1140 of data processing unit 1130. As another example, DMA engine 1120 can read data from local memory 1140 of data processing unit 1130 and write data into memory 1110. DMA engine 1120 provides a DMA feature that allows data processing unit 1130 to initiate data transfer between memory 1110 and local memories 1140 of the data processing units 1130 and to perform other operations while the data transfer is being conducted. In some embodiments, DMA engine 1120 may read tensors from memory 1110, modify the tensors in a way that is optimized for data processing unit 1130 before it writes the tensors into local memories 1140 of data processing units 1130.
[0078] Data processing units 1130 perform deep learning operations in DNNs. For instance, data processing unit 1130 may execute a DNN layer by running one or more deep learning operations in the DNN layer. Data processing unit 1130 may execute a layer, or a portion of a layer, at a time. In some embodiments, the operations of the DNN layers may be run by multiple data processing units 1130 in parallel. For instance, multiple data processing units 1130 may each perform a data processing workload, or a portion of a data processing workload for a deep learning operation. Data may be shared between data processing units 1130. Data processing unit 1130 may also be referred to as a compute block, or a compute tile.
[0079] Data processing units 1130 may be capable of running various types of deep learning operations, such as convolution, layer normalization, SoftMax operation, pooling, elementwise operation, linear operation, non-linear operation, and so on. Deep learning operations performed by the data processing units 1130 include tensor operations, i.e., operations whose inputs are tensors or operations whose outputs are tensors. In an example, data processing unit 1130 receives an input tensor and one or more convolutional kernels and performs a convolution with the input tensor and convolutional kernels. The result of the convolution may be an output tensor, which can be further computed, e.g., by data processing unit 1130 or another data processing unit 1130.
[0080] In the embodiments of FIG. 11, each data processing unit 1130 includes local memory 1140, descriptor fetch state machine 1188, load module 1160, processing engine 1170, post-processing engine 1180, and output module 1190. Data processing unit 1130 may include a data processing pipeline that includes load module 1160, processing engine 1170, post-processing engine 1180, and output module 1190. Some or all the components of the data processing unit 1130 can be implemented on the same chip. In other embodiments, alternative configurations, different or additional components may be included in the data processing unit 1130. Further, functionality attributed to a component of data processing unit 1130 may be accomplished by a different component included in the data processing unit 1130, a different data processing unit 1130, another component of the DNN accelerator 1102, or a different system. A component of the data processing unit 1130 may be implemented in hardware, software, firmware, or some combination thereof.
[0081] Local memory 1140 is local to the corresponding data processing unit 1130. In the embodiments of FIG. 3, local memory 1140 is inside the data processing unit 1130. In other embodiments, local memory 1140 may be outside the data processing unit 1130. Local memory 1140 may include one or more SRAMs. The capacity of local memory 1140 (e.g., 1.5-2 MB) may be far smaller than the capacity of memory 1110. Data in local memory 1140 may be transferred to or from memory 1110, or cache 1112, e.g., through DMA engine 1120. In some embodiments, data in local memory 1140 may be transferred to or from local memory 1140 of another data processing unit 1130. Local memory 1140 may store data received, used, or generated by load module 1160, processing engine 1170, post-processing engine 1180, or output module 1190. Examples of the data may include input activations, weights, output activations, low-level machine instructions, configuration descriptors, and so on.
[0082] In some embodiments, local memory 1140 may store tensors to be processed by the processing engine 1170 or the post-processing engine 1180. The tensors may be input tensors of deep learning operations. Local memory 1140 may also store tensors generated by processing engine 1170 or post-processing engine 1180. The tensors may be output tensors of deep learning operations. The layout of data points of a tensor in local memory 1140 may depend on the format in which the tensor is stored. In some embodiments, local memory 1140 may store tensors in various formats, including Z-major format, X-major format, and Y-major format. For a tensor with Z-major format, the local memory 1140 may store data points having the same (x, y) coordinate contiguously. For instance, the data points having the same (x, y) coordinate may be stored at a sequence of memory addresses the local memory 1140. For a tensor with the ZXY format or ZYX format, local memory 1140 may store data points having the same (x, y) coordinate contiguously. For instance, the data points having the same (x, y) coordinate may be stored at a sequence of memory addresses in local memory 1140. For a tensor with X-major format, local memory 1140 may store data points having the same (y, z) coordinate contiguously. For a tensor with Y-major format, local memory 1140 may store data points having the same (x, z) coordinate contiguously.
[0083] In some embodiments, local memory 1140 may store dense tensors (e.g., dense activation tensors, dense weight tensors, etc. ) , sparse tensors (e.g., sparse activation tensors, sparse weight tensors, etc. ) , and so on. A dense tensor may be a tensor from which zero-valued elements (if any) are not removed. A dense tensor may be converted to a sparse tensor by removing one or more zero-valued elements in the dense tensor. A sparse tensor may also be referred to as a compressed tensor or packed tensor. The process of converting a dense tensor to a sparse tensor may be referred to as sparsity encoding. Sparsity encoding may also generate a sparsity tensor. Each element in the sparsity tensor may correspond to a different element in the dense tensor and indicate whether the element in the dense tensor is zero or not. The sparsity tensor may indicate positions of elements of the sparse tensor in the dense tensor. The sparsity tensor may include a sparsity bitmap, each element of which is a bit. A sparse tensor may be converted to a dense tensor through a densifying process, in which one or more zeros may be added to the sparse tensor based on the sparsity tensor.
[0084] In some embodiments, local memory 1140 includes one or more SRAMs. Local memory 1140 may be byte-addressable, and each memory address identifies a single byte (eight bits) of storage. In some embodiments, local memory 1140 may include memory banks. The number of data banks in the local memory 1140 may be 16, 64, 128, 356, 512, 1024, 2048, or other numbers. A memory bank may include a plurality of storage units. In an example, a data bank may include 8, 16, 64, or a different number of storage units. A memory bank or a storage unit in a memory bank may have a memory address. In an example, a storage unit may store a single byte, and data larger than a single byte may be stored in storage units with consecutive memory addresses, i.e., adjacent storage units. For instance, a storage unit can store an integer number in the INT8 format, versus two storage units may be needed to store a number in the FP16 or BF16 format, which has 16 bits. In some embodiments, 16 bits can be transferred from local memory 1140 in a single read cycle. In other embodiments, 16 bits can be transferred from local memory 1140 in multiple read cycles, such as two cycles.
[0085] Load module 1160 loads data from local memory 1140 to the processing engine 1170 or to post-processing engine 1180. Load module 1160 may load data from local memory 1140 to one or more data buffers of the processing engine 1170. Load module 1160 may read tensors from the local memory 1140. The tensors may include sparse activation tensors, sparse weight tensors, activation sparsity tensors, weight sparsity tensors, and so on.In some embodiments, load module 1160 may load data based on a sparsity mode. Load module 1160 may select different data to transmit to the processing engine 1170 in different sparsity modes.
[0086] Descriptor fetch state machine 1188 can load instructions, e.g., configuration descriptors and / or low-level machine instructions, from outside of data processing unit 1130 to local memory 1140. The instructions may be used to configure or control processing cells of processing engine 1170 to perform one or more deep neural network operations. The instructions may be used to configure or control post-processing engine 1180 to perform one or more operations such as applying an activation function. Descriptor fetch state machine 1188 may include hardware logic (e.g., logic gates and / or circuitry) arranged to perform the logic operations of a state machine. Additional details relating to descriptor fetch state machine 1188 are described with FIG. 14.
[0087] In some embodiments, descriptor fetch state machine 1188 may be included with data processing unit 1130 to manage loading of configuration descriptors onto data processing unit 1130 (e.g., local memory 1140, or register files provided in data processing unit 1130) . In some embodiments, descriptor fetch state machine 1188 may be included with DNN accelerator 1102 to manage loading of configuration descriptors onto memory 1110. In some embodiments, descriptor fetch state machine 1188 may be included with DNN accelerator 1102 to manage loading of configuration descriptors onto cache 1112.
[0088] Processing engine 1170 performs neural network operations of DNNs. An exemplary processing engine 1170 is described and illustrated in FIG. 12.
[0089] Post-processing engine 1180 processes outputs of processing engine 1170. The post-processing engine 1180 may include one or more post-processing elements. In some embodiments, the post-processing elements in the post-processing engine 1180 may be arranged in an arrangement (e.g., in an array arrangement) that has rows and columns. In some embodiments, post-processing engine 1180 computes activation functions. Post-processing engine 1180 may receive outputs of processing engine 1170 as inputs to the activation functions. In addition or alternative to activation functions, post-processing engine 1180 may perform other types of post-processing on outputs of processing engine 1170. For instance, post-processing engine 1180 may apply a bias on an output of processing engine 1170. For instance, post-processing engine 1180 may perform scaling on an output of processing engine 1170. In some embodiments, post-processing engine 1180 may be bypassed for certain neural network operations.
[0090] Output module 1190 drains data from processing engine 1170 and / or from post-processing engine 1180. Output module 1190 may write the data to local memory 1140. The drained data may be tensors, such as output tensors of neural network operations. In some embodiments, output module 1190 may drain data on a cell level of processing engine 1170. For each processing cell, output module 1190 may drain outputs of processing elements in the processing cell based on a row index or column index of each processing element. For instance, output module 1190 may use a sequence of cycles to drain data from a processing cell. Output module 1190 may drain the output of some of the processing elements in each cycle. The sequence of the cycles may be configured based on a configuration parameter indicating the operation mode of load module 1160. The drained data, e.g., tensors, may be further loaded to memory 1110, e.g., through the DMA engine 1120. Additionally or alternatively, the drained data may be loaded by the load module 1160 to the processing engine 1170 for further computation, e.g., for performing a deep learning operation in the next layer.
[0091] FIG. 12 illustrates processing engine 1170, according to some embodiments of the disclosure. Processing engine 1170 may be included as part of a data processing unit, such as data processing unit 1130 of FIG. 11. Processing engine 1170 may include one or more processing cells 1202. In some embodiments, processing cells 1202 may be arranged in one or more rows and / or one or more columns in the processing engine 1170. In some embodiments, processing cells 1202 may be arranged as one or more sets or arrays of processing cells 1202 performing different operations. Processing engine 1170 may have one or more arrays of multiply and accumulate circuity (e.g., processing cells 1202) optimized to perform compute operations such as matrix multiplication and convolution.
[0092] Each processing cell may include one or more processing elements. In some cases, a processing cell includes a single processing element. In some cases, a processing cell includes a plurality of processing elements. The processing elements may be arranged as an array. The processing elements may be arranged in rows and / or columns. In some cases, a processing cell may include processing element (s) that perform the same operation. In some cases, a processing cell may include processing element (s) that perform different operations. In some cases, at least some of the processing element (s) in a processing cell may be arranged to perform operations in parallel. In some cases, at least some of the processing element (s) in a processing cell may be arranged to perform operations serially.
[0093] A processing element may perform an arithmetic operation associated with neural network operations or DNN operations. In some cases, the one or more processing elements that may be arranged in an array that includes rows and columns. Examples of processing elements may include a multiply unit, a division unit, a scaling unit, an adding unit, an accumulator unit a subtractor unit, a logarithmic unit, an exponentiation unit, a multiply-accumulate (MAC) unit, a bit shift unit, a square root unit, etc. The processing elements in processing cells may be arranged to perform an arithmetic operation on a vector of inputs to generate a vector of outputs (in parallel) , sometimes referred to as vector processing. The processing elements in processing cells may perform scalar operations.
[0094] Processing engine 1170 may include controller 1204, which may configure circuitry of one or more processing cells 1202 to perform the arithmetic operations. In some cases, controller 1204 may configure one or more processing cells 1202 (or individual processing elements in a processing cell 1202) to perform operations in a particular sequence or manner. In some cases, controller 1204 may configure one or more processing cells 1202 (or individual processing elements in a processing cell 1202) according to instructions (e.g., configuration descriptors, and / or low-level machine instructions) loaded in instruction buffer 1206. Controller 1204 may include a program counter to determine the instructions loaded in instruction buffer 1206 to be executed by one or more processing cells 1202 (or individual processing elements in a processing cell 1202) .
[0095] The instructions (e.g., configuration descriptors, and / or low-level machine instructions) loaded in instruction buffer 1206 may signal which processing cells 1202 (or individual processing elements in a processing cell 1202) is to execute or carry out one or more operations. Instruction buffer 1206 may include one or more register files, or one or more arrays of memory cells.
[0096] Data may be loaded in data buffers 1208 by controller 1204 and / or load module 1160 of FIG. 11. The data may be used by processing cells 1202. Data produced by processing cells 1202 may be drained from data buffers 1208 by output module 1190 to local memory 1140 of FIG. 11. Data buffers 1208 may include one or more register files, or one or more arrays of memory cells.
[0097] Capacity of the instruction buffer 1206 and / or the data buffers 1208 may be on the order of kilobytes (KBs) .
[0098] Data buffers 1208 may include one or more of: one or more input data buffers, and one or more output data buffers. Data buffers 1208 may include one or more weights / parameters buffers. Data buffers 1208 may store operands for one or more processing elements of processing cell 1202. Data buffers 1208 may store generated outputs of one or more processing elements of processing cell 1202.
[0099] The instructions (e.g., configuration descriptors, and / or low-level machine instructions) loaded in instruction buffer 1206 may signal which data stored in data buffers 1208 is to be processed by processing cells 1202 (or individual processing elements in a processing cell 1202) . In some cases, the processing cells 1202 (or individual processing elements in a processing cell 1202) may read data from data buffers 1208 at a default location for the processing cell 1202 or an individual processing element in the processing cell 1202.
[0100] The instructions (e.g., configuration descriptors, and / or low-level machine instructions) loaded in instruction buffer 1206 may signal where to store output data in data buffers 1208 after processing cells 1202 produces the output data. In some cases, the processing cells 1202 (or individual processing elements in a processing cell 1202) may write data to data buffers 1208 at a default location for the processing cell 1202 or an individual processing element in the processing cell 1202.
[0101] Load module 1160 of FIG. 11 may load data to certain locations in data buffers 1208. Output module 1190 of FIG. 11 may drain data from data buffers 1208 to be stored in local memory 1140 and / or memory 1110 of FIG. 11.
[0102] FIG. 13 illustrates post-processing engine 1180, according to some embodiments of the disclosure. As discussed previously with FIG. 11, post-processing engine 1180 may process the output (e.g., a tensor) produced by processing engine 1170. Some exemplary components in post-processing engine 1180 are depicted. In some embodiments, post-processing engine 1180 may include bias 1302 to add a bias to the output produced by processing engine 1170. In some embodiments, post-processing engine 1180 may include scale 1304 to scale (e.g., multiply by a number) the output produced by processing engine 1170. In some embodiments, post-processing engine 1180 may include output conversion 1360, which may convert the data to different precisions such as integer precision, floating-point precision, etc. Output conversion 1360 may convert data between precisions such as INT8, FP16, FP32, etc. Output conversion 1360 may perform quantization according to a quantization specified in a configuration descriptor.
[0103] In some embodiments, post-processing engine 1180 may include a software programmable look up table (LUT) 388. LUT 1388 may be loaded with look up table values provided in a configuration descriptor (e.g., from local memory 1140 and / or memory 1110) , making LUT 1388 software configurable. The look up table values include parameters for approximating a function, such as an activation function.
[0104] In some embodiments, post-processing engine 1180 may apply an approximated version (e.g., using linear approximation) of an activation function to the output produced by processing engine 1170 using LUT 1388. Post-processing engine 1180 may include address logic 1306, LUT 1388, and computation unit 1310, to apply the approximated version of the activation function. Specifically, LUT 1388 may store one or more look up table values provided in a configuration descriptor that configures post-processing engine 1180. The look up table values may approximate a function, such as an activation function or another suitable function. Specifically, the look up table values include parameters for linear segments that approximate the activation function. The linear segments may correspond to different portions of the input range. In some cases, the look up table values may include parameters for other types of segments, such as saturation segments or fixed segments. At different addresses of LUT 1388, LUT 1388 may store one or more look up table values that specify the segments corresponding to a particular portion of the input range. Parameters for a linear segment can include a slope of a line and an intercept of the line corresponding to the linear segment.
[0105] When post-processing engine 1180 receives an input data element, address logic 1306 may identify the segment to which the input data element belongs, and therefore the location (e.g., address of LUT 1388) where parameters for the segments would be stored. Address logic 1306 may determine the address of LUT 1388 that is storing one or more look up table values that can be used to calculate an approximation of the function being applied to the input data element (e.g., one or more parameters that specify the segment) . The one or more look up table values may be retrieved from LUT 1388 and provided to computation unit 1310. Computation unit 1310 may compute an output of a linear function corresponding to the linear segment using the one or more look up table values, e.g., the one or more parameters that specify the linear segment. Computation unit 1310 may perform multiplication and adding to determine the output of the linear function. Specifically, computation unit 1310 may multiply the input data element by a slope of the linear function and add the result of the multiplication by an intercept of the linear function (where both the slope and the intercept may be stored in LUT 1388 at the address determined by address logic 1306. The output of the linear function calculated by computation unit 1310 serves as the approximated output of the function being approximated by LUT 1388. In another example where the input data element corresponds to a saturation segment, computation unit 1310 may be bypassed. A saturation value may be retrieved from LUT 1388 and used as the approximated output of the function being approximated by LUT 1388.
[0106] One or more outputs produced by post-processing engine 1180 may be provided to local memory 1140 of data processing unit 1130 via output module 1190 of FIG. 11.
[0107] Referring back to FIGS. 11-13, DNN system 1100 illustrates one implementation of a processor designed to accelerate execution of DNNs. The architecture design of a processor can vary depending on the application requirements of the processor. The architecture design can vary based on the number of DPUs, the number of processing engines, the number of processing cells, the number of post-processing engines, structure of the data processing pipeline in a DPU, support for vector processing, support for sparsity modes, the types or collection of processing elements, amount of memory and buffer size, etc.
[0108] Exemplary hardware descriptor fetch state machine
[0109] For some neural network hardware accelerators (such as DNN accelerator 1102) , a MatMul operation in a neural network definition or a processing graph determined from the neural network definition can be mapped to one or more data processing workloads that can be executed on a DPU of the neural network hardware accelerator. The one or more data processing workloads can be encoded using one or more configuration descriptors. A configuration descriptor has fields describing and specifying the layer-level characteristics to perform the operation. Using the compact configuration descriptor format as illustrated in FIGS. 8-9, the configuration descriptors are further optimized for performance, where the configuration descriptor is broken into a “variant” part (e.g., a variable configuration descriptor illustrated in FIG. 9) and into an “invariant” part (e.g., a constant configuration descriptor illustrated in FIG. 8) .
[0110] In some embodiments, the compact configuration descriptor format splitting the configuration descriptor can be applied with a high reuse factor when mapping a MatMul layer to many data processing workloads performing a common operation. Consider a MatMul layer in a transformer-based neural network which may be split into D data processing workloads, a compiler can produce the invariant part, e.g., the constant configuration descriptor, and reuse the invariant part for the D data processing workloads. The compiler can produce the variant parts, e.g., the variable configuration descriptors, corresponding to the D data processing workloads. A DPU can be augmented with logic to fetch the variant and invariant parts of the configuration descriptor (e.g., the constant configuration descriptor, and the variable configuration descriptor) for the first data processing workload. Then, for all subsequent data processing workloads, the DPU only needs to fetch the variant part (e.g., the variable configuration descriptor) . This provides the benefit of reuse across the data processing workloads of a single MatMul layer. Reuse of the constant configuration descriptor can be extended to other kinds of reuse. The reuse can go beyond a single layer, a constant configuration descriptor enables reusing common descriptor fields between MatMul layers within a block, between MatMul layers across blocks, and between experts in the mixture of experts (as illustrated in FIGS. 5-7) .
[0111] To facilitate a DPU to quickly determine whether the DPU needs to fetch the constant configuration descriptor or if one already stored in on-chip memory (e.g., SRAM) can be reused for executing the next data processing workload, the compiler can generate unique tags for reused, constant configuration descriptors. The unique tags can be conveyed in a variable size descriptor (e.g., a descriptor having metadata about a variable configuration descriptor) to identify a particular constant configuration descriptor. The DPU can check the tag in the variable size descriptor to quickly determine whether fetching a new / different constant configuration descriptor is needed for the next data processing workload.
[0112] FIG. 14 illustrates a variable size descriptor format, according to some embodiments of the disclosure. The variable size descriptor can include one or more of: a memory pointer to a constant configuration descriptor ( “CONST_PTR” ) , a tag value for the constant configuration descriptor ( “CONST_TAG” ) , and a memory pointer to a variable configuration descriptor ( “VAR_PTR” ) .
[0113] The memory pointer to a variable configuration descriptor ( “VAR_PTR” ) allows the DPU to fetch the variable configuration descriptor.
[0114] The tag value for a constant configuration descriptor ( “CONST_TAG” ) includes the unique tag that identifies the constant configuration descriptor. Examples of unique tags may include e.g., unique identifiers, unique names, and hash values. A tag value may include a hash value of the constant configuration descriptor. A hash value may be produced by applying a pre-determined hash function to the one or more fields of the constant configuration descriptor or the entirety of the constant configuration descriptor. A tag value may include unique identifiers that uniquely identifies various constant configuration descriptors produced by the compiler. A tag value may include unique names such as TAG_WITHIN_BLOCK_REUSE, TAG_ACROSS_BLOCK_REUSE, TAG_WITHIN_MOE_REUSE, etc.
[0115] The memory pointer to the constant configuration descriptor ( “CONST_PTR” ) allows the DPU to fetch the constant configuration descriptor (if a different / new constant configuration descriptor is needed for the next data processing workload) and load the constant configuration descriptor onto a memory of DPU.
[0116] FIG. 15 illustrates a state machine, according to some embodiments of the disclosure. The state machine may be implemented in descriptor fetch state machine 1188 illustrated in FIG. 11.
[0117] The state machine is in the IDLE state 1502 until a (new) data processing workload is ready and valid.
[0118] In response to a new valid data processing workload being present, the state machine transitions to FETCH DESCRIPTOR state 1504. In FETCH DESCRIPTOR state 1504, the state machine may determine whether the compact configuration descriptor format is used or the full configuration descriptor format is used. The state machine may check whether a flag for the new valid data processing workload indicates that the compact configuration descriptor format is used. The compact configuration descriptor format has a constant part (having one or more fields) and a variant part (having one or more fields) . The flag may indicate that the new valid data processing workload has a configuration descriptor that is split into a constant configuration descriptor and a variable configuration descriptor. The flag may indicate that the new valid data processing workload has a configuration descriptor that follows the full configuration descriptor format.
[0119] In response to the flag indicating that the compact configuration descriptor is not used (e.g., COMPACT DESCRIPTOR FLAG = 0, the configuration descriptor follows the full configuration descriptor format) , the state machine proceeds to fetch the configuration descriptor for the new valid data processing workload and transitions to START OPERATION state 1510.
[0120] In response to the flag indicating that the compact configuration descriptor is used (e.g., COMPACT DESCRIPTOR FLAG = 1) , the state machine transitions to FETCH VARIABLE SIZE DESCRIPTOR state 1506.
[0121] The state machine may determine that the flag for the further data processing workload indicates the further data processing workload uses a compact configuration descriptor format (e.g., has the constant configuration descriptor and the variable configuration descriptor) . The subsequent fetching of the variable size descriptor (e.g., in FETCH VARIABLE SIZE DESCRIPTOR state 1506) is performed in response to determining that the flag indicates the further data processing workload uses the compact configuration descriptor format.
[0122] In FETCH VARIABLE SIZE DESCRIPTOR state 1506, the state machine retrieves a variable size descriptor using a format as illustrated in FIG. 14. The variable size descriptor may include a tag value for a constant configuration descriptor for the new valid data processing workload. The state machine may determine whether the tag value of the constant configuration descriptor matches (e.g., is the same as, corresponds to, equals to, etc. ) a tag value of the constant configuration descriptor used for executing a previous data processing workload. The state machine retrieves the variable configuration descriptor using a memory pointer to the variable configuration descriptor in the variable size descriptor.
[0123] In response to the tag value of the constant configuration descriptor in the variable size descriptor matching the tag value of the constant configuration descriptor of the previous data processing workload (e.g., CONSTANT TAG MATCH) , the state machine transitions to START OPERATION state 1510. The state machine skips the FETCH CONSTANT DESCRIPTOR state 1508. Because the tag value matches, the state machine detects that the constant configuration descriptor already previously loaded onto memory does not need to be fetched again and can be reused for the new valid data processing workload.
[0124] In response to the tag value of the constant configuration descriptor in the variable size descriptor not matching the tag value of the constant configuration descriptor of the previous data processing workload (e.g., CONSTANT TAG MISMATCH) , the state machine transitions to FETCH CONSTANT DESCRIPTOR state 1508.
[0125] In FETCH CONSTANT DESCRIPTOR state 1508, the state machine fetches the variable configuration descriptor using a memory pointer to the constant configuration descriptor in the variable size descriptor. The state machine then transitions to START OPERATION state 1510.
[0126] In START OPERATION state 1510, the state machine has loaded a configuration descriptor using the full configuration descriptor format if the state machine has transitioned to START OPERATION state 1510 from FETCH DESCRIPTOR state 1504. The state machine is ready to signal and signals to the DPU to execute the next valid data processing task using the configuration descriptor. The state machine transitions to START OPERATION state 1510.
[0127] In START OPERATION state 1510, the state machine has confirmed that a constant configuration descriptor has been loaded to memory and a variable configuration descriptor using the compact configuration descriptor format has been fetched if the state machine has transitioned to START OPERATION state 1510 from FETCH VARIABLE SIZE DESCRIPTOR state 1506. The state machine is ready to signal and signals to the DPU to execute the next valid data processing task using the constant configuration descriptor and the variable configuration descriptor. The state machine transitions to START OPERATION state 1510.
[0128] In START OPERATION state 1510, the state machine has fetched a constant configuration descriptor and a variable configuration descriptor using the compact configuration descriptor format if the state machine has transitioned to START OPERATION state 1510 from FETCH CONSTANT DESCRIPTOR state 1508. The state machine is ready to signal and signals to the DPU to execute the next valid data processing task using the constant configuration descriptor and the variable configuration descriptor. The state machine transitions to START OPERATION state 1510.
[0129] The state machine may transition to END OPERATION state 1512 when the state machine receives a signal that the data processing task is completed or done. The state machine may transition back to IDLE state 1502 to wait for another valid data processing workload.
[0130] Considering a scenario where a data processing workload and a further data processing workload share a common operation. The data processing workload may be associated with a neural network operation such as MatMul. The further data processing workload may be associated with the same neural network operation or a further neural network operation such as MatMul. The data processing workloads may have common fields or common configurations. A compiler may group the data processing workload and the further data processing workload together for reuse when producing configuration descriptors. The compiler may generate a constant configuration descriptor for both data processing workloads, a variable configuration descriptor for the data processing workload, and a further variable configuration descriptor for the further data processing workload.
[0131] The state machine may detect that the compact configuration descriptor is used (e.g., using a flag) for the data processing workload. The state machine is triggered to transition to FETCH VARIABLE SIZE DESCRIPTOR state 1506. The state machine may retrieve a variable size descriptor for the data processing workload in FETCH VARIABLE SIZE DESCRIPTOR state 1506. Given that the data processing workload is a first task, the state machine will fetch a variable size descriptor using the memory pointer to the variable size descriptor in the variable size descriptor in FETCH VARIABLE SIZE DESCRIPTOR state 1506 and transition to FETCH CONSTANT DESCRIPTOR state 1508. In FETCH CONSTANT DESCRIPTOR state 1508, the state machine fetches the constant configuration descriptor using the memory pointer to the constant configuration descriptor (e.g., CONST_PTR) in the variable size descriptor. The state machine loads the variable configuration descriptor and the constant configuration descriptor of the data processing workload onto a memory of a data processing unit (of a neural network hardware accelerator) . The constant configuration descriptor is associated with a tag value (for identifying the constant configuration descriptor) . The constant configuration descriptor includes one or more fields instructing the data processing unit to execute a neural network operation according to one or more configurations.
[0132] Once the DPU has received both the constant configuration descriptor and the variable configuration descriptor, the DPU has all the configuration data to execute the data processing workload (e.g., a MatMul operation) . The state machine may send a start signal to the DPU and transition to the START OPERATION state 1510. The state machine may signal to the data processing unit to execute the data processing workload.
[0133] Once the DPU has completed the execution of the data processing workload (e.g.., a MatMul operation) , the DPU may signal the completion of the data processing workload using a done signal. The done signal may the state machine to transition to the END OPERATION state 1512.
[0134] The state machine goes back to the IDLE state 1502 and waits for a new valid data processing workload, such as the further data processing workload that shares a common operation with the data processing workload.
[0135] The further data processing workload may trigger the state machine to transition to the FETCH DESCRIPTOR state 1504 and restarts the descriptor fetching process for the further data processing workload.
[0136] During the processing of the further data processing workload, the state machine will first fetch the variable size descriptor. The state machine may fetch a variable size descriptor of the further data processing workload. The variable size descriptor has a further tag value. The further data processing workload can share a common operation with the data processing workload. The further tag value may match the tag value associated with the constant configuration descriptor of the data processing workload.
[0137] During the processing of the variable size descriptor, the state machine will check the programmed tag value, e.g., CONST_TAG, in the variable size descriptor. The state machine may determine whether the further tag value matches the tag value associated with the constant configuration descriptor (of the data processing workload) .
[0138] If the programmed tag value matches the tag value associated with the constant configuration descriptor of the data processing workload, then the fetching of the constant configuration descriptor is skipped. In the scenario where the tag values match, the data processing workload and the further data processing workload both include the (the same) neural network operation to be executed according to the one or more (same) configurations. In response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, the state machine may signal to the data processing unit to execute the further data processing workload using the constant configuration descriptor in the memory. In response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, the state machine may skip the loading of the constant configuration descriptor onto the memory.
[0139] On the other hand, if the programmed tag value doesn’t match the tag value associated with the constant configuration descriptor of the data processing workload, then the state machine fetches a further constant configuration descriptor to complete the further data processing workload using on the memory pointer to the further constant configuration descriptor (e.g., CONST_PTR field in the variable size descriptor) . In response to determining that the further tag value does not match the tag value of the constant configuration descriptor, the state machine may load a further constant configuration descriptor using a memory pointer to the further constant configuration descriptor in the variable size descriptor onto the memory. The state machine may signal the data processing unit to execute the further data processing workload using the further constant configuration descriptor in the memory.
[0140] Regardless of whether the programmed tag value matches the tag value associated with the constant configuration descriptor, the state machine may load a further variable configuration descriptor onto the memory using a further memory pointer to the further variable configuration descriptor in the variable size descriptor. The data processing unit can then execute the further data processing workload using further variable configuration descriptor and the constant configuration descriptor in the memory.
[0141] The advantage of this state machine is that it saves memory bandwidth for the neural network hardware accelerator, as it is not necessary to refetch the constant configuration descriptor across the execution of the data processing workloads that share a common operation (e.g., data processing workloads that reuse the same constant configuration descriptor) . Skipping the fetching of the constant configuration descriptor when the tag value matches a tag value of a previous constant configuration descriptor already loaded onto the memory enables the reuse across the data processing workloads, within the same block. The state machine can be used for saving memory bandwidth even for reuse across different blocks or across the experts in an MOE model, as long as the state machine can check the tag value of a variable size descriptor against one or more tag values of constant configuration descriptors it has loaded onto the memory (and thus does not require re-fetching) . Reusing the constant configuration descriptor already loaded onto the memory can save valuable on-chip SRAM memory and effectively allow more of the memory to be used to store activations and the ever-growing weights.
[0142] When the compiler can exploit the reuse and group the data processing workloads that share a common operation, the neural network hardware accelerator can effectively save memory bandwidth and reduce the on-chip SRAM usage for storing configuration descriptors, which improves the overall performance of the neural network hardware accelerator.
[0143] Exemplary DNN module including a compiler
[0144] FIG. 16 illustrates DNN module 1101, according to some embodiments of the disclosure. DNN module 1101 includes interface module 1610, training module 1620, validating module 1640, compiler 1650, and datastore 1660. In other embodiments, alternative configurations, different or additional components may be included in the DNN module 1101. Further, functionality attributed to a component of DNN module 1101 may be accomplished by a different component included in DNN module 1101 or a different module or system.
[0145] Interface module 1610 facilitates communications of DNN module 1101 with other modules or systems. For example, interface module 1610 establishes communications between DNN module 1101 with an external datastore to receive data that can be used to train DNNs or input into DNNs to perform tasks. As another example, interface module 1610 supports DNN module 1101 to distribute DNNs to other systems, e.g., computing devices configured to apply DNNs to perform tasks.
[0146] Training module 1620 trains DNNs by using a training dataset. Training module 1620 forms the training dataset. In an example where training module 1620 trains an DNN to recognize objects in images, the training dataset includes training images and training labels. The training labels describe ground-truth classifications of objects in the training images. In some embodiments, each label in the training dataset corresponds to an object in a training image. In an example where training module 1620 trains a transformer-based neural network to predict the next token, the training data set may include a large library of sequences of tokens. In some embodiments, a part of the training dataset may be used to initially train the DNN, and the rest of the training dataset may be held back as a validation subset used by validating module 1640 to validate performance of a trained DNN. The portion of the training dataset not including the tuning subset and the validation subset may be used to train the DNN.
[0147] Training module 1620 also determines hyperparameters for training the DNN. Hyperparameters are variables specifying the DNN training process. Hyperparameters are different from parameters inside the DNN (e.g., weights of filters) . In some embodiments, hyperparameters include variables determining the architecture of the DNN, such as number of hidden layers, etc. Hyperparameters also include variables which determine how the DNN is trained, such as batch size, number of epochs, etc. A batch size defines the number of training samples to work through before updating the parameters of the DNN. The batch size is the same as or smaller than the number of samples in the training dataset. The training dataset can be divided into one or more batches. The number of epochs defines how many times the entire training dataset is passed forward and backwards through the entire network. The number of epochs defines the number of times that the deep learning algorithm works through the entire training dataset. One epoch means that each training sample in the training dataset has had an opportunity to update the parameters inside the DNN. An epoch may include one or more batches. The number of epochs may be 1, 5, 10, 50, 100, 500, 1000, or even larger.
[0148] Training module 1620 can define the architecture of the DNN, e.g., based on some of the hyperparameters. In some cases, training module 1620 may receive a model definition that defines or specifies the architecture of the DNN. The architecture of the DNN can include a plurality of layers. Examples of layers may include convolutional layers, pooling layers, fully connected layers, normalization layers, SoftMax or logit layers, and so on. After training module 1620 defines the architecture of the DNN, training module 1620 inputs a training dataset into the DNN. The training dataset includes a plurality of training samples. The training module 1620 modifies the parameters inside the DNN ( “internal parameters of the DNN” ) to minimize the error between labels of the training objects that are generated by the DNN and the ground-truth labels of the objects. The internal parameters include weights used in layers of the DNN. In some embodiments, the training module 1620 uses a cost function to minimize the error.
[0149] Training module 1620 may train the DNN for a pre-determined number of epochs. The number of epochs is a hyperparameter that defines the number of times that the deep learning algorithm will work through the entire training dataset. One epoch means that each sample in the training dataset has had an opportunity to update internal parameters of the DNN. After training module 1620 finishes the pre-determined number of epochs, training module 1620 may stop updating the parameters in the DNN. The DNN having the updated parameters is referred to as a trained DNN.
[0150] Validating module 1640 verifies accuracy of trained DNNs. In some embodiments, validating module 1640 inputs samples in a validation dataset into a trained DNN and uses the outputs of the DNN to determine the model accuracy. In some embodiments, a validation dataset may be formed of some or all the samples in the training dataset. Additionally or alternatively, the validation dataset includes additional samples, other than those in the training sets. In some embodiments, validating module 1640 may determine an accuracy score measuring the precision, recall, or a combination of precision and recall of the DNN. The validating module 1640 may use the following metrics to determine the accuracy score: Precision = TP / (TP + FP) and Recall = TP / (TP + FN) , where precision may be how many the DNN correctly predicted (TP or true positives) out of the total it predicted (TP + FP or false positives) , and recall may be how many the DNN correctly predicted (TP) out of the total number of objects that did have the property in question (TP +FN or false negatives) . The F-score (F-score = 2 *PR / (P + R) ) unifies precision and recall into a single measure.
[0151] Validating module 1640 may compare the accuracy score with a threshold score. In an example where validating module 1640 determines that the accuracy score of the DNN is less than the threshold score, validating module 1640 instructs th training module 1620 to re-train the DNN. In one embodiment, training module 1620 may iteratively re-train the DNN until the occurrence of a stopping condition, such as the accuracy measurement indication that the DNN may be sufficiently accurate, or a number of training rounds having taken place.
[0152] Compiler 1650 compiles information associated with DNNs which can be used to cause DNN accelerator 1102 of FIG. 11 to carry out neural network operations for DNNs. The information may include the model definition, one or more processing graphs, one or more data processing workloads produced from the one or more processing graphs, and executable instructions (e.g., configuration descriptors and / or low-level machine instructions) that can be executed by DNN accelerator 1102. The model definition may include one or more neural network operations to be performed by the DNN. In some embodiments, compiler 1650 may generate a processing graph representing a DNN. The graph may include nodes and edges. A node may represent a specific neural network operation in the DNN. An edge may connect two nodes and represent a connection between the two corresponding neural network operations. In an example, an edge may encode a tensor that flows from one of the neural network operations to the other neural network operation. The tensor may be an output tensor of the first neural network operation and an input tensor of the second neural network operation. The edge may encode one or more attributes of the tensor, such as size, shape, storage format, and so on.
[0153] Compiler 1650 may pre-process the processing graph to identify reuse opportunities to reduce the size of the compiled configuration descriptors. Compiler 1650 may apply logic to identify data processing workloads with a common operation and generate variable configuration descriptors for the repeat operators. Compiler 1650 may perform memory allocation to ensure that constant configuration descriptors are stored in a fast memory. The configuration descriptors can be used and executed by components of the DNN accelerator 1102 (e.g., processing engine 1170 and post-processing engine 1180 of FIG. 11) to execute the DNN. An exemplary compiler 1650 is described and illustrated in FIG. 17.
[0154] Datastore 1660 stores data received, generated, used, or otherwise associated with the DNN module 1101. For example, datastore 1660 stores the datasets used by training module 1620 and validating module 1640. Datastore 1660 may also store data generated by training module 1620 and validating module 1640, such as the hyperparameters for training DNNs, internal parameters of trained DNNs (e.g., weights, etc. ) , data for sparsity acceleration (e.g., sparsity bitmap, etc. ) , and so on. Datastore 1660 may store configuration parameters, configuration descriptors, instructions generated by compiler 1650, etc. The datastore 1660 may include one or more memories. In the embodiment of FIG. 4, datastore 1660 is a component of DNN module 1101. In other embodiments, datastore 1660 may be external to DNN module 1101 and communicate with the DNN module 1101 through a network.
[0155] FIG. 17 illustrates compiler 1650, according to some embodiments of the disclosure. Compiler 1650 includes neural network analyzer 1702, identify reuse pattern 1704 configuration descriptors generator 1708, scheduler 1710, and memory allocation 1712. Compiler 1650 implements one or more features to identify reuse patterns and utilize the compact configuration descriptor format for grouped data processing workloads that share a common operation.
[0156] Neural network analyzer 1702 may analyze a DNN and determine how a neural network hardware accelerator can implement the DNN utilizing the DPUs of the accelerator. Neural network analyzer 1702 may receive the neural network model definition of the DNN. A neural network model definition may specify one or more layers of a neural network. For example, a neural network model definition may specify layers of the neural network and how the data should flow through the layers. A layer can be specified by the neural network operation that the layer performs. Examples of layers can include fully connected (linear) layer, convolutional layer, recurrent layer, long short-term memory network, gated recurrent unit layer, max pooling layer, average pooling layer, batch normalization layer, normalization layer, dropout layer, activation layer, embedding layer, etc. The layer can be specified by one or more of: input size, hidden size, output size, etc. The layer can be specified by one or more parameters of the neural network operation (e.g., for a convolutional layer, one or more parameters may include kernel size, padding, stride, etc. ) .
[0157] In some cases, neural network analyzer 1702 may determine a processing graph based on the neural network model definition. A processing graph may include connected nodes. The connected nodes can represent neural network operations to be executed by one or more data processing units and an order of execution of the neural network operations. The edges connecting the nodes can represent the flow of data between the neural network operations. Examples of neural network operations can include: a compute operation, convolution, filtering, pooling, matrix multiplication, applying an activation function (clamping function, exponential function, sigmoid function, power function, square root function, etc. ) , etc. An edge connecting a node and a further node that follows the node may represent that an output generated by the node is to be provided as an input to the further node. The processing graph may include one or more neural network operations to be executed by one or more DPUs (of the neural network hardware accelerator) .
[0158] Neural network analyzer 1702 may determine one or more data processing workloads to be carried out by the DPUs (of the neural network hardware accelerator) based on the processing graph and / or the neural network model definition. The one or more data processing workloads may correspond to and / or include one or more neural network operations of the processing graph. For example, a data processing workload may include one or more neural network operations to be executed according to one or more configurations. The data processing workload may be executed by a data processing pipeline of a data processing unit, such as a processing engine of a data processing unit, or a post-processing engine of a data processing unit. In some cases, a neural network operation may translate to a data processing workload. In some cases, a neural network operation may translate to multiple data processing workloads. In some cases, one or more neural network operations may translate to one or more data processing workloads. The neural network operations can be executed by a data processing pipeline of a data processing unit, such as a processing engine of a data processing unit, or a post-processing engine of a data processing unit. The neural network operations can be executed by one or more data processing units or one or more parts of a data processing unit, according to the order of execution represented by the processing graph. A neural network operation of a data processing workload may be executed by a data processing unit according to one or more configurations for the neural network operation. In some cases, the neural network model definition includes the processing graph.
[0159] As illustrated by FIGS. 5-7 and discussed in the overview, there are opportunities for grouping data processing workloads that share a common (the same) operation. Identify reuse pattern 1704 may determine whether a data processing workload and a further data processing workload associated with one or more neural network operations to be executed by one or more data processing units (of a neural network hardware accelerator) share a common (the same) operation. For example, the data processing workload and the further data processing workload may both be MatMul operations with one or more of the same configurations (e.g., shape configurations) but operating on different data. In some embodiments, identify reuse pattern 1704 may determine whether a data processing workload and a further data processing workload include a same neural network operation to be executed according to one or more same configurations. Identify reuse pattern 1704 may group data processing workloads that can share a constant configuration descriptor during the compilation process. Identify reuse pattern 1704 may implement an algorithm to identify reuse patterns and group the data processing workloads accordingly.
[0160] In some embodiments, identify reuse pattern 1704 may traverse through the processing graph determined by neural network analyzer 1702 to find data processing workloads that share a common (or same) operation. Identify reuse pattern 1704 may determine whether the data processing workload and the further data processing workload share the common operation by determining whether a hash value of the data processing workload and a further hash value of the further data processing workload are the same. Identify reuse pattern 1704 may determine determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation by determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same. Identify reuse pattern 1704 may consider one or more configurations of different data processing workloads when identifying reuse patterns, the one or more configurations can include: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration. When the data processing workload and the further data processing workload share one or more of the same configurations for a same neural network operation, identify reuse pattern 1704 may determine that the two workloads share a common / same operation, and can share the same constant configuration descriptor.
[0161] The hash value of the data processing workload may be calculated by applying a pre-determined hash function on one or more configurations of the data processing workload, such as an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration. The further hash value of the further data processing workload may be calculated by applying the pre-determined hash function on one or more configurations of the further data processing workload, such as an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.
[0162] In some embodiments, identify reuse pattern 1704 may determine whether the data processing workload and the further data processing workload share the common (or same) operation comprises determining whether the data processing workload and the further data processing workload have one or more configurations which are the same. The one or more configurations may include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration
[0163] In some embodiments, identify reuse pattern 1704 may build a dictionary having keys and values corresponding to the keys. Identify reuse pattern 1704 may traverse through the processing graph and using the hash values of the data processing workloads as keys. Using the hash value of a given data processing workload as a key, the data processing workload can be appended to the value corresponding to the key. The resulting dictionary can group data processing workloads that share a common operation using the keys of the dictionary. A value corresponding to a key in the dictionary includes one or more data processing workloads that share a common operation.
[0164] Configuration descriptors generator 1708 may generate one or more configuration descriptors using the compact configuration descriptor format illustrated in FIGS. 8-9. In response to determining that the data processing workload and the further data processing workload share a common operation, configuration descriptors generator 1708 may generate a constant configuration descriptor for the data processing workload and the further data processing workload. In some cases, the configuration descriptors generator 1708 may generate the constant configuration descriptor in response to determining that the data processing workload and the further data processing workload include the same neural network operation to be executed according to the same one or more same configurations. The constant configuration descriptor can include one or more fields that instruct one or more data processing units to execute the same neural network operation according to the one or more same configurations. The constant configuration descriptor may include one or more (invariant) fields which are common to both the data processing workload and the further data processing workload (hence the constant configuration descriptor can be shared) . Configuration descriptors generator 1708 may generate a variable configuration descriptor for the data processing workload. The variable configuration descriptor may include one or more memory pointers. The variable configuration descriptor may include one or more (variant) fields which are unique to the data processing workload (e.g., the further processing workload would have different register configurations for those fields) . Configuration descriptors generator 1708 may generate a further variable configuration descriptor for the further data processing workload. The further variable configuration descriptor may include one or more further memory pointers. The further variable configuration descriptor may include one or more (variant) fields which are unique to the further data processing workload (e.g., the data processing workload would have different register configurations for those fields) .
[0165] In some cases, the data processing workload and the further processing workload specify the same neural network operation (with the same configurations) to be applied to different data and may generate different data. In such cases, the variable configuration descriptor and the further variable configuration descriptor would include fields which specify different configurations for where to fetch and / or write data, such as different memory pointers.
[0166] Configuration descriptors generator 1708 may generate a constant configuration descriptor for a group of data processing workloads that share the same operation. Configuration descriptors generator 1708 may generate respective variable configuration descriptors for the data processing workloads that share the same operation.
[0167] In some embodiments, configuration descriptors generator 1708 may generate the variable configuration descriptor by determining a memory pointer referring to a memory location of the constant configuration descriptor and including the memory pointer in the variable configuration descriptor. Configuration descriptors generator 1708 may generate the further variable configuration descriptor by including the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor. The memory pointer referring to a memory location of the constant configuration descriptor may be determined by memory allocation 1712. Variable configuration descriptors can include a reference or pointer to the (shared) constant configuration descriptor to significantly save the total number of bytes needed to specify all the necessary register configurations for data processing workloads that share a common (or same) neural network operation.
[0168] The following is pseudocode of compiler 1650 representing operations performed in identify reuse pattern 1704 and configuration descriptors generator 1708.
[0169] In some embodiments configuration descriptors generator 1708 may use the full configuration descriptor format to generate configuration descriptors for data processing workloads that do not share a common operator with other data processing workloads.
[0170] Scheduler 1710 may coordinate when and which DPUs should have the configuration descriptors generated by configuration descriptors generator 1708 loaded to execute the data processing workloads. The data processing workloads may be allocated by scheduler 1710 to the DPUs (in a neural network hardware accelerator) , and scheduler 1710 may coordinate to have the corresponding configuration descriptors (or one or more parts of a configuration descriptor) provided to the DPUs. In some cases, scheduler 1710 may determine a plan that can load balance execution of the data processing workloads. Scheduler 1710 may determine a plan that ensures the data processing workloads are being executed according to the processing graph. Scheduler 1710 may determine a plan to cause a configuration descriptor or a portion of a configuration descriptor to be loaded onto a DPU at an appropriate time. In some cases, scheduler 1710 may be a part of compiler 1650. In some cases, scheduler 1710 may be a part of DNN module 1101 of FIGS. 3-4.
[0171] To further benefit from using the compact configuration descriptor format, compiler 1650 may include memory allocation 1712 to optimize where the constant configuration descriptors are to be stored so that loading the constant configuration descriptors onto local memory and / or register files of a DPU can be done quickly. Unlike variable configuration descriptors, which are used only once, constant configuration descriptors are reused repeatedly during inference and can have a much longer lifecycle.
[0172] FIG. 18 illustrates memory accesses to fetch a constant configuration descriptor, according to some embodiments of the disclosure. As discussed with FIG. 15, descriptor fetch state machine 1188 may be fetching a constant configuration descriptor repeatedly. There may be multiple options for where to store a constant configuration descriptor, e.g., local memory 1140, cache 1112, and memory 1110. In some implementations, the capacity of memory 1110 may be significantly greater than the capacity of local memory 1140 or the capacity of cache 1112. The capacity of cache 1112 may be smaller than the capacity of local memory 1140. Memory 1110-may include DRAM. Local memory 1140 may include SRAM. Cache 1112 may include SRAM. Data processing unit 1130, e.g., descriptor fetch state machine 1188, may have fastest access to local memory 1140. Accessing data from memory 1110 (outside of data processing unit 1130) may take longer than accessing local memory 1140. Accessing data from cache 1112 (outside of data processing unit 1130) may be faster than accessing data from memory 1110 since cache 1112 may serve as a (fast) cache for memory 1110.
[0173] Given that the size of the compact, lightweight configuration descriptors is significantly reduced, a local memory of a DPU (e.g., SRAM, or local memory 1140 of FIG. 11) can store the constant configuration descriptor workloads, thereby avoiding memory traffic from slower memory (e.g., memory 1110 of FIG. 11 or DRAM) . In some cases, the constant configuration descriptor may be stored in local memory 1140, if space is available. Referring back to FIG. 17, memory allocation 1712 may generate a memory allocation instruction for the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit of the neural network hardware accelerator (e.g., local memory 1140 of FIG. 11) carrying out the data processing workload and the further data processing workload. In some embodiments, memory allocation 1712 may generate a memory allocation instruction instructing the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit executing one or more of: the data processing workload and the further data processing workload.
[0174] Capacity of local memory 1140 may be limited. If the local memory of a DPU (e.g., SRAM) lacks sufficient space, the compiler (e.g., compiler 1650) can allocate the constant configuration descriptors to a lower-level cache, such as the memory-side cache (e.g., cache 1112 of FIG. 11) . In some cases, the constant configuration descriptor may be cached in cache 1112 if space is not available on local memory 1140. Referring back to FIG. 17, memory allocation 1712 may generate a memory allocation instruction for the constant configuration descriptor to be cached in a cache for a dynamic random access memory of the neural network hardware accelerator (e.g., cache 1112 of FIG. 11) carrying out the data processing workload and the further data processing workload. In some embodiments, memory allocation 1712 may generate a memory allocation instruction instructing the constant configuration descriptor to be cached in a cache for a dynamic random access memory accessible by the one or more data processing units executing the data processing workload and the further data processing workload
[0175] In some implementations, SRAM and DRAM are two types of RAMs. SRAM may store data in transistors in the form of voltage. DRAM may store data in capacitors in the form of electric charges. SRAM can be faster (has faster access speeds) and more expensive to manufacture and include on-chip, whereas DRAM can be slower (slower access speeds) and less expensive to manufacture and include on-chip.
[0176] Exemplary methods for enabling reuse of a constant configuration descriptor to reduce size of compiled configuration descriptors
[0177] FIG. 19 is a flowchart showing method 1900 for generating configuration descriptors, according to some embodiments of the disclosure. The method may be performed to configure one or more data processing units to execute one or more neural network operations of a neural network. The one or more data processing units can be configured to perform the one or more neural network operations using the generated configuration descriptors. The one or more data processing units may be a part of one or more of: a hardware processor, a DNN accelerator, a neural network hardware accelerator having one or more data processing units, field programmable gate array, hardware logic, hardware circuitry, application-specific integrated circuit, etc. Method 1900 can be performed using a computing device, such as computing device 2100 in FIG. 21. Method 1900 may be performed using one or more parts of compiler 1650 seen in FIG. 17. Method 1900 may be an exemplary method performed by DNN module 1101 or compiler 1650.
[0178] In 1902, it is determined that a data processing workload and a further data processing workload include a same neural network operation to be executed by the one or more data processing units according to one or more same configurations.
[0179] In 1904, a constant configuration descriptor is generated for the data processing workload and the further data processing workload. The constant configuration descriptor includes one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations.
[0180] In 1906, a variable configuration descriptor is generated for the data processing workload. The variable configuration descriptor includes one or more memory pointers.
[0181] In 1908, a further variable configuration descriptor is generated for the further data processing workload. The further variable configuration descriptor having one or more further memory pointers.
[0182] One or more of 1904, 1906, and 1908 may be performed in response to determining that the data processing workload and the further data processing workload include the same neural network operation to be executed according to the one or more same configurations.
[0183] Exemplary methods for saving memory bandwidth
[0184] FIG. 20 is a flowchart showing method 2000 for fetching configuration descriptors, according to some embodiments of the disclosure. Method 2000 may be performed by descriptor fetch state machine 1188 illustrated in FIG. 11. Method 2000 may implement the state machine illustrated in FIG. 15. Method 2000 may be performed by a hardware state machine, which can be implemented as part of, e.g., one or more of: a data processing unit, a hardware processor, a DNN accelerator, a neural network hardware accelerator having one or more data processing units, field programmable gate array, hardware logic, hardware circuitry, application-specific integrated circuit, etc.
[0185] In 2002, a variable configuration descriptor and a constant configuration descriptor of a data processing workload are loaded onto a memory of a data processing unit. The constant configuration descriptor is associated with a tag value. The constant configuration descriptor includes one or more fields instructing the data processing unit to execute a neural network operation according to one or more configurations.
[0186] In 2004, a signal is sent to the data processing unit to execute the data processing workload.
[0187] In 2006, a variable size descriptor of a further data processing workload is fetched. The variable size descriptor has a further tag value.
[0188] In 2008, in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, a further signal is sent to the data processing unit to execute the further data processing workload using the constant configuration descriptor in the memory.
[0189] Comparison between using the full configuration descriptor format and using the compact configuration descriptor format when compiling a 7-billion parameter LLM model
[0190] Exemplary computing device
[0191] FIG. 21 is a block diagram of an apparatus or a system, e.g., an exemplary computing device 2100, according to some embodiments of the disclosure. One or more computing devices 2100 may be used to implement the functionalities described with the FIGS. and herein. A number of components illustrated in FIG. 11 can be included in the computing device 2100, but any one or more of these components may be omitted or duplicated, as suitable for the application. In some embodiments, some or all of the components included in the computing device 2100 may be attached to one or more motherboards. In some embodiments, some or all of these components are fabricated onto a single system on a chip (SoC) die. Additionally, in various embodiments, the computing device 2100 may not include one or more of the components illustrated in FIG. 21, and the computing device 2100 may include interface circuitry for coupling to the one or more components. For example, the computing device 2100 may not include a display device 2106, and may include display device interface circuitry (e.g., a connector and driver circuitry) to which a display device 2106 may be coupled. In another set of examples, the computing device 2100 may not include an audio input device 2118 or an audio output device 2108 and may include audio input or output device interface circuitry (e.g., connectors and supporting circuitry) to which an audio input device 2118 or audio output device 2108 may be coupled.
[0192] The computing device 2100 may include a processing device 2102 (e.g., one or more processing devices, one or more of the same types of processing device, one or more of different types of processing device) . The processing device 2102 may include electronic circuitry that process electronic data from data storage elements (e.g., registers, memory, resistors, capacitors, quantum bit cells) to transform that electronic data into other electronic data that may be stored in registers and / or memory. Examples of processing device 2102 may include a CPU, a graphical processing unit (GPU) , a quantum processor, a machine learning processor, an artificial intelligence processor, a neural network processor, an artificial intelligence accelerator, an application-specific integrated circuit (ASIC) , an analog signal processor, an analog computer, a microprocessor, a digital signal processor, a field programmable gate array (FPGA) , a tensor processing unit (TPU) , a neural network hardware accelerator, a DNN accelerator (e.g., DNN accelerator 1102 as illustrated in FIGS. 3, and 5-6) , etc.
[0193] The computing device 2100 may include a memory 2104, which may itself include one or more memory devices such as volatile memory (e.g., DRAM) , nonvolatile memory (e.g., read-only memory (ROM) ) , high bandwidth memory (HBM) , flash memory, solid state memory, and / or a hard drive. Memory 2104 includes one or more non-transitory computer-readable storage media. In some embodiments, memory 2104 may include memory that shares a die with the processing device 2102.
[0194] In some embodiments, memory 2104 includes one or more non-transitory computer-readable media storing instructions executable to perform operations described with the FIGS. and herein, such as the methods and operations illustrated in FIGS. 19-20. In some embodiments, memory 2104 includes one or more non-transitory computer-readable media storing instructions executable to perform operations of method 1900. In some embodiments, memory 2104 includes one or more non-transitory computer-readable media storing instructions executable to perform operations of method 2000. Exemplary parts, e.g., DNN module 1101 and compiler 1650, that may be encoded as instructions and stored in memory 2104 are depicted. Memory 2104 may store instructions that encode one or more exemplary parts, such as DNN module 1101, one or more parts of DNN module 1101, compiler 1650, and / or one or more parts of compiler 1650. The instructions stored in the one or more non-transitory computer-readable media may be executed by processing device 2102.
[0195] In some embodiments, memory 2104 may store data, e.g., data structures, binary data, bits, metadata, files, blobs, etc., as described with the FIGS. and herein. Memory 2104 may store compiled configuration descriptors described herein, e.g., constant configuration descriptors and variable configuration descriptors. Memory 2104 may store a neural network definition. Memory 2104 may store a processing graph. Memory 2104 may store data processing workloads that can implement the processing graph. Memory 2104 may store the dictionary that groups data processing workloads that share a common operation.
[0196] In some embodiments, memory 2104 may store one or more DNNs (and or parts thereof) . Memory 2104 may store training data for training (trained) a DNN. Memory 2104 may store instructions that perform operations associated with training a DNN. Memory 2104 may store input data, output data, intermediate outputs, intermediate inputs of one or more DNNs. Memory 2104 may store one or more parameters used by the one or more DNNs. Memory 2104 may store information that encodes how nodes of the one or more DNNs are connected with each other. Memory 2104 may store instructions to perform one or more operations of the one or more DNNs. Memory 2104 may store a model definition that specifies one or more operations of a DNN. Memory 2104 may store instructions, such as configuration descriptors, that are generated by a compiler based on the model definition.
[0197] In some embodiments, the computing device 2100 may include a communication device 2112 (e.g., one or more communication devices) . For example, the communication device 2112 may be configured for managing wired and / or wireless communications for the transfer of data to and from the computing device 2100. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a nonsolid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not. The communication device 2112 may implement any of a number of wireless standards or protocols, including but not limited to Institute for Electrical and Electronic Engineers (IEEE) standards including Wi-Fi (IEEE 802.10 family) , IEEE 802.16 standards (e.g., IEEE 802.16-2005 Amendment) , Long-Term Evolution (LTE) project along with any amendments, updates, and / or revisions (e.g., advanced LTE project, ultramobile broadband (UMB) project (also referred to as "3GPP2" ) , etc. ) . IEEE 802.16 compatible Broadband Wireless Access (BWA) networks are generally referred to as WiMAX networks, an acronym that stands for worldwide interoperability for microwave access, which is a certification mark for products that pass conformity and interoperability tests for the IEEE 802.16 standards. The communication device 2112 may operate in accordance with a Global System for Mobile Communication (GSM) , General Packet Radio Service (GPRS) , Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) , Evolved HSPA (E-HSPA) , or LTE network. The communication device 2112 may operate in accordance with Enhanced Data for GSM Evolution (EDGE) , GSM EDGE Radio Access Network (GERAN) , Universal Terrestrial Radio Access Network (UTRAN) , or Evolved UTRAN (E-UTRAN) . The communication device 2112 may operate in accordance with Code-division Multiple Access (CDMA) , Time Division Multiple Access (TDMA) , Digital Enhanced Cordless Telecommunications (DECT) , Evolution-Data Optimized (EV-DO) , and derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond. The communication device 2112 may operate in accordance with other wireless protocols in other embodiments. The computing device 2100 may include an antenna 2122 to facilitate wireless communications and / or to receive other wireless communications (such as radio frequency transmissions) . The computing device 2100 may include receiver circuits and / or transmitter circuits. In some embodiments, the communication device 2112 may manage wired communications, such as electrical, optical, or any other suitable communication protocols (e.g., the Ethernet) . As noted above, the communication device 2112 may include multiple communication chips. For instance, a first communication device 2112 may be dedicated to shorter-range wireless communications such as Wi-Fi or Bluetooth, and a second communication device 2112 may be dedicated to longer-range wireless communications such as global positioning system (GPS) , EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, or others. In some embodiments, a first communication device 2112 may be dedicated to wireless communications, and a second communication device 2112 may be dedicated to wired communications.
[0198] The computing device 2100 may include power source / power circuitry 2114. The power source / power circuitry 2114 may include one or more energy storage devices (e.g., batteries or capacitors) and / or circuitry for coupling components of the computing device 2100 to an energy source separate from the computing device 2100 (e.g., DC power, AC power, etc. ) .
[0199] The computing device 2100 may include a display device 2106 (or corresponding interface circuitry, as discussed above) . The display device 2106 may include any visual indicators, such as a heads-up display, a computer monitor, a projector, a touchscreen display, a liquid crystal display (LCD) , a light-emitting diode display, or a flat panel display, for example.
[0200] The computing device 2100 may include an audio output device 2108 (or corresponding interface circuitry, as discussed above) . The audio output device 2108 may include any device that generates an audible indicator, such as speakers, headsets, or earbuds, for example.
[0201] The computing device 2100 may include an audio input device 2118 (or corresponding interface circuitry, as discussed above) . The audio input device 2118 may include any device that generates a signal representative of a sound, such as microphones, microphone arrays, or digital instruments (e.g., instruments having a musical instrument digital interface (MIDI) output) .
[0202] The computing device 2100 may include a GPS device 2116 (or corresponding interface circuitry, as discussed above) . The GPS device 2116 may be in communication with a satellite-based system and may receive a location of the computing device 2100, as known in the art.
[0203] The computing device 2100 may include a sensor 2130 (or one or more sensors) . The computing device 2100 may include corresponding interface circuitry, as discussed above) . Sensor 2130 may sense physical phenomenon and translate the physical phenomenon into electrical signals that can be processed by, e.g., processing device 2102. Examples of sensor 2130 may include: capacitive sensor, inductive sensor, resistive sensor, electromagnetic field sensor, light sensor, camera, imager, microphone, pressure sensor, temperature sensor, vibrational sensor, accelerometer, gyroscope, strain sensor, moisture sensor, humidity sensor, distance sensor, range sensor, time-of-flight sensor, pH sensor, particle sensor, air quality sensor, chemical sensor, gas sensor, biosensor, ultrasound sensor, a scanner, etc.
[0204] The computing device 2100 may include another output device 2110 (or corresponding interface circuitry, as discussed above) . Examples of the other output device 2110 may include an audio codec, a video codec, a printer, a wired or wireless transmitter for providing information to other devices, haptic output device, gas output device, vibrational output device, lighting output device, home automation controller, or an additional storage device.
[0205] The computing device 2100 may include another input device 2120 (or corresponding interface circuitry, as discussed above) . Examples of the other input device 2120 may include an accelerometer, a gyroscope, a compass, an image capture device, a keyboard, a cursor control device such as a mouse, a stylus, a touchpad, a bar code reader, a Quick Response (QR) code reader, any sensor, or a radio frequency identification (RFID) reader.
[0206] The computing device 2100 may have any desired form factor, such as a handheld or mobile computer system (e.g., a cell phone, a smart phone, a mobile internet device, a music player, a tablet computer, a laptop computer, a netbook computer, a personal digital assistant (PDA) , a personal computer, a remote control, wearable device, headgear, eyewear, footwear, electronic clothing, etc. ) , a desktop computer system, a server or other networked computing component, a printer, a scanner, a monitor, a set-top box, an entertainment control unit, a vehicle control unit, a digital camera, a digital video recorder, an Internet-of-Things device, or a wearable computer system. In some embodiments, the computing device 2100 may be any other electronic device that processes data.
[0207] Select examples
[0208] Example 1 provides a method for configuring one or more data processing units to execute one or more neural network operations, including determining that a data processing workload and a further data processing workload include a same neural network operation to be executed by the one or more data processing units according to one or more same configurations; generating a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations; generating a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; and generating a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.
[0209] Example 2 provides the method of example 1, further including determining a memory pointer referring to a memory location of the constant configuration descriptor; and including the memory pointer referring to the memory location of the constant configuration descriptor in the variable configuration descriptor.
[0210] Example 3 provides the method of example 2, further including including the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor.
[0211] Example 4 provides the method of any one of examples 1-3, where: determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation includes determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same.
[0212] Example 5 provides the method of any one of examples 1-4, where the one or more same configurations for the same neural network operation include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.
[0213] Example 6 provides the method of any one of examples 1-5, further including generating a memory allocation instruction instructing the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit executing one or more of: the data processing workload and the further data processing workload.
[0214] Example 7 provides the method of any one of examples 1-5, further including generating a memory allocation instruction instructing the constant configuration descriptor to be cached in a cache for a dynamic random access memory accessible by the one or more data processing units executing the data processing workload and the further data processing workload.
[0215] Example 8 provides the method of any one of examples 1-7, where the one or more fields in the constant configuration descriptor includes one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.
[0216] Example 9 provides the method of any one of examples 1-8, where the one or more memory pointers in the variable configuration descriptor include a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor.
[0217] Example 10 provides the method of any one of examples 1-9, where the one or more further memory pointers the further variable configuration descriptor includes a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.
[0218] Example 11 provides a method, including loading a variable configuration descriptor and a constant configuration descriptor of a data processing workload onto a memory of a data processing unit, where the constant configuration descriptor is associated with a tag value, and includes one or more fields instructing the data processing unit to execute a neural network operation according to one or more configurations; signaling to the data processing unit to execute the data processing workload; fetching a variable size descriptor of a further data processing workload, the variable size descriptor having a further tag value; and in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, signaling to the data processing unit to execute the further data processing workload using the constant configuration descriptor in the memory.
[0219] Example 12 provides the method of example 11, further including in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, skipping loading of the constant configuration descriptor onto the memory.
[0220] Example 13 provides the method of example 11 or 12, further including in response to determining that the further tag value does not match the tag value of the constant configuration descriptor: loading a further constant configuration descriptor using a memory pointer to the further constant configuration descriptor in the variable size descriptor onto the memory; and signaling the data processing unit to execute the further data processing workload using the further constant configuration descriptor in the memory.
[0221] Example 14 provides the method of any one of examples 11-13, further including loading a further variable configuration descriptor onto the memory using a further memory pointer to the further variable configuration descriptor in the variable size descriptor; where the data processing unit executes the further data processing workload using the further variable configuration descriptor and the constant configuration descriptor in the memory.
[0222] Example 15 provides the method of any one of examples 11-14, further including determining that a flag for the further data processing workload indicates the further data processing workload uses a compact configuration descriptor format having a constant part and a variant part; where fetching the variable size descriptor is performed in response to determining that the flag indicates the further data processing workload uses the compact configuration descriptor format.
[0223] Example 16 provides the method of any one of examples 11-15, where the tag value associated with the constant configuration descriptor includes a hash value of the constant configuration descriptor.
[0224] Example 17 provides the method of any one of examples 11-16, where the tag value includes a unique identifier of the constant configuration descriptor.
[0225] Example 18 provides the method of any one of examples 11-17, where: the constant configuration descriptor is loaded from a cache of a dynamic random access memory; the dynamic random access memory is slower than the memory of the data processing unit; and the cache of the dynamic random access memory is faster than the dynamic random access memory.
[0226] Example 19 provides the method of any one of examples 11-18, where the memory includes a static random access memory.
[0227] Example 20 provides one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to: determine that a data processing workload and a further data processing workload include a same neural network operation to be executed by one or more data processing units according to one or more same configurations; generate a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations; generate a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; and generate a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.
[0228] Example 21 provides the one or more non-transitory computer-readable media of example 20, where the instructions further cause the one or more processors to: determine a memory pointer referring to a memory location of the constant configuration descriptor; and include the memory pointer referring to the memory location of the constant configuration descriptor in the variable configuration descriptor.
[0229] Example 22 provides the one or more non-transitory computer-readable media of example 21, where the instructions further cause the one or more processors to: include the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor.
[0230] Example 23 provides the one or more non-transitory computer-readable media of any one of examples 20-22, where: determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation includes determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same.
[0231] Example 24 provides the one or more non-transitory computer-readable media of any one of examples 21-23, where the one or more same configurations for the same neural network operation include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.
[0232] Example 25 provides the one or more non-transitory computer-readable media of any one of examples 21-24, where the instructions further cause the one or more processors to: generate a memory allocation instruction instructing the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit executing one or more of: the data processing workload and the further data processing workload.
[0233] Example 26 provides the one or more non-transitory computer-readable media of any one of examples 21-25, where the instructions further cause the one or more processors to: generating a memory allocation instruction instructing the constant configuration descriptor to be cached in a cache for a dynamic random access memory accessible by the one or more data processing units executing the data processing workload and the further data processing workload.
[0234] Example 27 provides the one or more non-transitory computer-readable media of any one of examples 21-26, where the one or more fields in the constant configuration descriptor includes one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.
[0235] Example 28 provides the one or more non-transitory computer-readable media of any one of examples 21-27, where the one or more memory pointers in the variable configuration descriptor include a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor.
[0236] Example 29 provides the one or more non-transitory computer-readable media of any one of examples 21-28, where the one or more further memory pointers the further variable configuration descriptor includes a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.
[0237] Example 30 provides an apparatus, including one or more processors; and one or more non-transitory computer-readable memories to store instructions, where the instructions, when executed by the one or more processors, cause the one or more processors to: determine that a data processing workload and a further data processing workload include a same neural network operation to be executed by one or more data processing units according to one or more same configurations; generate a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations; generate a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; and generate a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.
[0238] Example 31 provides the apparatus of example 30, where the instructions further cause the one or more processors to: determine a memory pointer referring to a memory location of the constant configuration descriptor; and include the memory pointer referring to the memory location of the constant configuration descriptor in the variable configuration descriptor.
[0239] Example 32 provides the apparatus of example 31, where the instructions further cause the one or more processors to: include the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor.
[0240] Example 33 provides the apparatus of any one of examples 30-32, where: determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation includes determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same.
[0241] Example 34 provides the apparatus of any one of examples 31-33, where the one or more same configurations for the same neural network operation include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.
[0242] Example 35 provides the apparatus of any one of examples 31-34, where the instructions further cause the one or more processors to: generate a memory allocation instruction instructing the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit executing one or more of: the data processing workload and the further data processing workload.
[0243] Example 36 provides the apparatus of any one of examples 31-35, where the instructions further cause the one or more processors to: generating a memory allocation instruction instructing the constant configuration descriptor to be cached in a cache for a dynamic random access memory accessible by the one or more data processing units executing the data processing workload and the further data processing workload.
[0244] Example 37 provides the apparatus of any one of examples 31-36, where the one or more fields in the constant configuration descriptor includes one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.
[0245] Example 38 provides the apparatus of any one of examples 31-37, where the one or more memory pointers in the variable configuration descriptor include a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor.
[0246] Example 39 provides the apparatus of any one of examples 31-38, where the one or more further memory pointers the further variable configuration descriptor includes a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.
[0247] Example 40 provides an apparatus, including one or more memories to store one or more configuration descriptors; and a data processing unit configurable by the one or more configuration descriptors to execute one or more neural network operations of a neural network, where the data processing unit includes hardware logic to: load a variable configuration descriptor and a constant configuration descriptor of a data processing workload onto the one or more memories, where the constant configuration descriptor is associated with a tag value, and includes one or more fields instructing the data processing unit to execute a neural network operation according to one or more configurations; signal to the data processing unit to execute the data processing workload using the variable configuration descriptor and the constant configuration descriptor in the one or more memories; fetch a variable size descriptor of a further data processing workload, the variable size descriptor having a further tag value; and in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, signal to the data processing unit to execute the further data processing workload using the constant configuration descriptor in the one or more memories.
[0248] Example 41 provides the apparatus of example 40, where the hardware logic is further to: in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, skip loading of the constant configuration descriptor onto the one or more memories.
[0249] Example 42 provides the apparatus of example 40 or 41, where the hardware logic is further to: in response to determining that the further tag value does not match the tag value of the constant configuration descriptor: load a further constant configuration descriptor using a memory pointer to the further constant configuration descriptor in the variable size descriptor onto the one or more memories; and signal the data processing unit to execute the further data processing workload using the further constant configuration descriptor in the one or more memories.
[0250] Example 43 provides the apparatus of any one of examples 40-42, where the hardware logic is further to: load a further variable configuration descriptor onto the one or more memories using a further memory pointer to the further variable configuration descriptor in the variable size descriptor; where the data processing unit executes the further data processing workload using the further variable configuration descriptor and the constant configuration descriptor in the one or more memories.
[0251] Example 44 provides the apparatus of any one of examples 40-43, where the hardware logic is further to: determine that a flag for the further data processing workload indicates the further data processing workload uses a compact configuration descriptor format having a constant part and a variant part; where fetching the variable size descriptor is performed in response to determining that the flag indicates the further data processing workload uses the compact configuration descriptor format.
[0252] Example 45 provides the apparatus of any one of examples 40-44, where the tag value associated with the constant configuration descriptor includes a hash value of the constant configuration descriptor.
[0253] Example 46 provides the apparatus of any one of examples 40-45, where the tag value includes a unique identifier of the constant configuration descriptor.
[0254] Example 47 provides the apparatus of any one of examples 40-46, where: the constant configuration descriptor is loaded from a cache of a dynamic random access memory; the dynamic random access memory is slower than the one or more memories; and the cache of the dynamic random access memory is faster than the dynamic random access memory.
[0255] Example 48 provides the apparatus of any one of examples 40-47, where the one or more memories includes a static random access memory.
[0256] Example A is an apparatus comprising means for carrying out any one of the methods according to examples 1-19.
[0257] Example B includes a DNN module as described and illustrated herein.
[0258] Example C includes a DNN module to carry out any one of the methods according to examples 1-10.
[0259] Example D includes a compiler as described and illustrated herein.
[0260] Example E includes a compiler to carry out any one of the methods according to examples 1-10.
[0261] Example F includes a DNN accelerator as described and illustrated herein.
[0262] Example G includes one or more data processing units as described and illustrated herein.
[0263] Example H includes a descriptor fetch state machine to carry out any one of the methods according to examples 11-19.
[0264] Example I includes a descriptor fetch state machine as described and illustrated herein.
[0265] Example J includes a DNN system comprising a DNN module according to example B or C and a DNN accelerator according to example F.
[0266] Variations and other notes
[0267] Although the operations of the example method shown in and described with reference to FIGS. 19-20 are illustrated as occurring once each and in a particular order, it will be recognized that the operations may be performed in any suitable order and repeated as desired. Additionally, one or more operations may be performed in parallel. Furthermore, the operations illustrated in FIGS. 19-20 may be combined or may include more or fewer details than described.
[0268] The various implementations described herein may refer to artificial intelligence, machine learning, and deep learning. Deep learning may be a subset of machine learning. Machine learning may be a subset of artificial intelligence. In cases where a deep learning model is mentioned, if suitable for a particular application, a machine learning model may be used instead. In cases where a deep learning model is mentioned, if suitable for a particular application, a digital signal processing system may be used instead.
[0269] The above description of illustrated implementations of the disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. While specific implementations of, and examples for, the disclosure are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the disclosure, as those skilled in the relevant art will recognize. These modifications may be made to the disclosure in light of the above detailed description.
[0270] For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the illustrative implementations. However, it will be apparent to one skilled in the art that the present disclosure may be practiced without the specific details and / or that the present disclosure may be practiced with only some of the described aspects. In other instances, well known features are omitted or simplified in order not to obscure the illustrative implementations.
[0271] Further, references are made to the accompanying drawings that form a part hereof, and in which are shown, by way of illustration, embodiments that may be practiced. It is to be understood that other embodiments may be utilized, and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense.
[0272] Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the disclosed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order from the described embodiment. Various additional operations may be performed or described operations may be omitted in additional embodiments.
[0273] For the purposes of the present disclosure, the phrase “A or B” or the phrase "A and / or B" means (A) , (B) , or (A and B) . For the purposes of the present disclosure, the phrase “A, B, or C” or the phrase "A, B, and / or C" means (A) , (B) , (C) , (A and B) , (A and C) , (B and C) , or (A, B, and C) . The term "between, " when used with reference to measurement ranges, is inclusive of the ends of the measurement ranges.
[0274] The description uses the phrases "in an embodiment" or "in embodiments, " which may each refer to one or more of the same or different embodiments. The terms "comprising, " "including, " "having, " and the like, as used with respect to embodiments of the present disclosure, are synonymous. The disclosure may use perspective-based descriptions such as "above, " "below, " "top, " "bottom, " and "side" to explain various features of the drawings, but these terms are simply for ease of discussion, and do not imply a desired or required orientation. The accompanying drawings are not necessarily drawn to scale. Unless otherwise specified, the use of the ordinal adjectives “first, ” “second, ” and “third, ” etc., to describe a common object, merely indicates that different instances of like objects are being referred to and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking or in any other manner.
[0275] In the following detailed description, various aspects of the illustrative implementations will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art.
[0276] The terms “substantially, ” “close, ” “approximately, ” “near, ” and “about, ” generally refer to being within + / -20%of a target value as described herein or as known in the art. Similarly, terms indicating orientation of various elements, e.g., “coplanar, ” “perpendicular, ” “orthogonal, ” “parallel, ” or any other angle between the elements, generally refer to being within + / -5-20%of a target value as described herein or as known in the art.
[0277] In addition, the terms “comprise, ” “comprising, ” “include, ” “including, ” “have, ” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, or device, that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such method, process, or device. Also, the term “or” refers to an inclusive “or” and not to an exclusive “or. ”
[0278] The systems, methods and devices of this disclosure each have several innovative aspects, no single one of which is solely responsible for all desirable attributes disclosed herein. Details of one or more implementations of the subject matter described in this specification are set forth in the description and the accompanying drawings.
Claims
1.A method for configuring one or more data processing units to execute one or more neural network operations, comprising:determining that a data processing workload and a further data processing workload include a same neural network operation to be executed by the one or more data processing units according to one or more same configurations;generating a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations;generating a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; andgenerating a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.2.The method of claim 1, further comprising:determining a memory pointer referring to a memory location of the constant configuration descriptor; andincluding the memory pointer referring to the memory location of the constant configuration descriptor in the variable configuration descriptor.3.The method of claim 2, further comprising:including the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor.4.The method of claim 1, wherein:determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation comprises determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same.5.The method of claim 1, wherein the one or more same configurations for the same neural network operation include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.6.The method of claim 1, further comprising:generating a memory allocation instruction instructing the constant configuration descriptor to be loaded onto a static random access memory of a data processing unit executing one or more of: the data processing workload and the further data processing workload.7.The method of claim 1, further comprising:generating a memory allocation instruction instructing the constant configuration descriptor to be cached in a cache for a dynamic random access memory accessible by the one or more data processing units executing the data processing workload and the further data processing workload.8.The method of claim 1, wherein the one or more fields in the constant configuration descriptor comprises one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.9.The method of claim 1, wherein the one or more memory pointers in the variable configuration descriptor comprise a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor.10.The method of claim 1, wherein the one or more further memory pointers the further variable configuration descriptor comprises a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.11.One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to:determine that a data processing workload and a further data processing workload include a same neural network operation to be executed by one or more data processing units according to one or more same configurations;generate a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations;generate a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; andgenerate a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.12.The one or more non-transitory computer-readable media of claim 11, wherein:determining that the data processing workload and the further data processing workload include the one or more same configurations for the same neural network operation comprises determining whether a hash value of one or more neural network operation configurations of the data processing workload and a further hash value of one or more further configurations of the further data processing workload are the same.13.The one or more non-transitory computer-readable media of claim 11, wherein the one or more same configurations for the same neural network operation include one or more of: an activation tensor shape configuration, an output tensor shape configuration, a weight tensor shape configuration, a data type configuration, a padding configuration, and a stride configuration.14.The one or more non-transitory computer-readable media of claim 11, wherein the one or more fields in the constant configuration descriptor comprises one or more of: an activation tensor shape field, a weight tensor shape field, an output tensor shape field, a data type field, a padding configuration field, a processing engine working mode configuration field, a post-processing engine working mode configuration field, a load module configuration field, and an output module configuration field.15.The one or more non-transitory computer-readable media of claim 11, wherein the one or more memory pointers in the variable configuration descriptor comprise a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor.16.The one or more non-transitory computer-readable media of claim 11, wherein the one or more further memory pointers the further variable configuration descriptor comprises a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.17.An apparatus, comprising:one or more processors; andone or more non-transitory computer-readable memories to store instructions, wherein the instructions, when executed by the one or more processors, cause the one or more processors to:determine that a data processing workload and a further data processing workload include a same neural network operation to be executed by one or more data processing units according to one or more same configurations;generate a constant configuration descriptor for the data processing workload and the further data processing workload, the constant configuration descriptor having one or more fields that instruct the one or more data processing units to execute the same neural network operation according to the one or more same configurations;generate a variable configuration descriptor for the data processing workload, the variable configuration descriptor having one or more memory pointers; andgenerate a further variable configuration descriptor for the further data processing workload, the further variable configuration descriptor having one or more further memory pointers.18.The apparatus of claim 17, wherein the instructions further cause the one or more processors to:determine a memory pointer referring to a memory location of the constant configuration descriptor; andinclude the memory pointer referring to the memory location of the constant configuration descriptor in the variable configuration descriptor.19.The apparatus of claim 18, wherein the instructions further cause the one or more processors to:include the memory pointer referring to the memory location of the constant configuration descriptor in the further variable configuration descriptor.20.The apparatus of claim 17, wherein:the one or more memory pointers in the variable configuration descriptor comprise a memory pointer referring to a memory location of the constant configuration descriptor, and one or more of: an address of an activation tensor, an address of a weight tensor, and an address of an output tensor; andthe one or more further memory pointers the further variable configuration descriptor comprises a memory pointer referring to the memory location of the constant configuration descriptor, and one or more of: a further address of an activation tensor, a further address of a weight tensor, and a further address of an output tensor.21.An apparatus, comprising:one or more memories to store one or more configuration descriptors; anda data processing unit configurable by the one or more configuration descriptors to execute one or more neural network operations of a neural network, wherein the data processing unit comprises hardware logic to:load a variable configuration descriptor and a constant configuration descriptor of a data processing workload onto the one or more memories, wherein the constant configuration descriptor is associated with a tag value, and includes one or more fields instructing the data processing unit to execute a neural network operation according to one or more configurations;signal to the data processing unit to execute the data processing workload using the variable configuration descriptor and the constant configuration descriptor in the one or more memories;fetch a variable size descriptor of a further data processing workload, the variable size descriptor having a further tag value; andin response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, signal to the data processing unit to execute the further data processing workload using the constant configuration descriptor in the one or more memories.22.The apparatus of claim 21, wherein the hardware logic is further to:in response to determining that the further tag value matches the tag value associated with the constant configuration descriptor, skip loading of the constant configuration descriptor onto the one or more memories.23.The apparatus of claim 21, wherein the hardware logic is further to:in response to determining that the further tag value does not match the tag value of the constant configuration descriptor:load a further constant configuration descriptor using a memory pointer to the further constant configuration descriptor in the variable size descriptor onto the one or more memories; andsignal the data processing unit to execute the further data processing workload using the further constant configuration descriptor in the one or more memories.24.The apparatus of claim 21, wherein the hardware logic is further to:load a further variable configuration descriptor onto the one or more memories using a further memory pointer to the further variable configuration descriptor in the variable size descriptor;wherein the data processing unit executes the further data processing workload using the further variable configuration descriptor and the constant configuration descriptor in the one or more memories.25.The apparatus of claim 21, wherein the hardware logic is further to:determine that a flag for the further data processing workload indicates the further data processing workload uses a compact configuration descriptor format having a constant part and a variant part;wherein fetching the variable size descriptor is performed in response to determining that the flag indicates the further data processing workload uses the compact configuration descriptor format.
Citation Information
Patent Citations
Instruction data processing method and device, equipment and storage medium
CN111240682A
Schedule-aware tensor distribution module
CN112149811A
Configurable processor element arrays for implementing convolutional neural networks
CN113033765A
Data processing method and apparatus, and related product
US20210334105A1
Data processing apparatus, data processing method and related product
WO2022134872A1