Patent Description:
<CIT> discloses a multi-processor computing system. The multi-processor computing system comprises a host processor, a global memory and at least one processing units, wherein the multi-processor computing system further comprises: a micro task sequencer, comprising a task acquisition device and a task scheduling device, wherein the task acquisition device is configured to fetch a command including micro task descriptions from the global memory if the micro task sequencer is capable to accommodate further commands, and the task scheduling device is configured to dispatch each micro task instruction defined by each of the micro task descriptions to one of the at least one processing units, so that the indicated processing unit can execute the micro task instruction, and the task scheduling device is further configured to detect the completion of all the micro tasks in the command and notify the host processor of the completion, wherein the processing unit can access the global memory by itself or by another of the at least one processing units.

Artificial Neural Networks (ANNs) are used to perform an increasing number and variety of tasks, such as, for example, object recognition, speech recognition, speech generation, providing recommendations, and predicting user behavior. Performing these tasks may be referred to as inferencing using an ANN model. To provide useful inferences, an ANN model needs to be designed and trained for the particular task. The ANN design establishes parameters such as the number of layers of the ANN model and the characteristics of each layer. The training of the ANN uses training data, inferencing using the ANN model, feedback based on evaluation of the inference, and backpropagation to adjust the weights of the ANN model in response to the feedback. After numerous training cycles of inferencing and backpropagation, the resultant model may provide satisfactory results in response to new input data. Note that many ANNs have multiple hidden layers between an input layer and an output layer and may consequently be referred to as Deep Neural Networks (DNNs).

To provide a satisfactory user experience, not only do the inference results need to be correct, but they also need to be provided fairly quickly - often within a fraction of a second (response latency within service level agreement). To do this, service providers use large arrays of inference accelerators located "in the cloud" - that is, communicatively coupled to, and located remotely from, a client device.

Client computer devices may include, for example, computers, automobiles, smartphones, smart wearable devices, and internet-of-things (IoT) devices. The so-called cloud may comprise a plurality of interconnected servers located at a data center and may be managed by a cloud provider entity such as, for example, Amazon. of Seattle, WA or Facebook, Inc. , of Menlo Park, CA. Each host server comprises a plurality of interconnected inference accelerators, which may be provided by an inference-accelerator provider entity. Each accelerator comprises processor and memory components.

The cloud may support many millions of neural network applications. A neural network application running on a client computer device communicates with the cloud to receive inference acceleration and/or assistance. For example, a speech-translation neural-network application (NNA) may transmit a raw or encoded audio snippet to the cloud for rapid translation and provision of the translation in response to the NNA. A media-recommendation program that recommends, e.g., songs or videos - where the media may comprise many millions, or even billions, of options hosted by the cloud provider in the cloud - may communicate with the cloud to have the cloud perform an inference to generate a recommendation for provision to a user of the client computer device.

In the data center context, various heterogenous architectures have been employed to handle machine learning workloads. For example, cloud compute may use server-class central processing units (CPUs) or graphics processing units (GPUs) and may adapt their workloads to those architecture. However, these architectures may not be tailored to the specific characteristics of machine learning algorithms, with the effect that their performance is not as efficient as desired, and/or they consume more power to achieve a given level of performance than would be desirable. As there may be many millions of NNAs accessing the inference accelerators of the cloud at any one time, efficient inference accelerators would be beneficial for reducing power usage and/or reducing inference time.

Thus, it would be desirable to provide an inference-accelerator computing architecture that is scalable to cloud computing and data center application, while providing improved performance per watt when compared to existing server-class CPU and GPU-based solutions.

Some advantages of the disclosed aspects may include providing a scalable architecture for cloud computing that provides improved interconnection between processing elements, and a compiler that produces a more efficient mapping of neural network operations onto available hardware.

<FIG> is a simplified schematic diagram of an exemplary inference accelerator <NUM> in accordance with an embodiment of the disclosure. The inference accelerator <NUM> comprises a system-on-chip (SoC) <NUM> coupled to a first double data rate (DDR) dynamic random-access memory (DRAM) <NUM> and a second DDR DRAM <NUM>. The SoC <NUM> comprises a first processing element <NUM>, a second processing element <NUM>, a third processing element <NUM>, and a fourth processing element <NUM>. The processing elements <NUM>, <NUM>, <NUM>, and <NUM> are coupled together via a compute network-on-chip (NoC) <NUM>. Note that the terms "NoC" and "network" may be used interchangeably herein. Note that inference accelerators in accordance with this disclosure are not limited to any particular number of processing elements and alternative implementations may have more or fewer than four processing elements.

The SoC <NUM> further comprises a first memory interface <NUM>, a second memory interface <NUM>, a third memory interface <NUM>, a fourth memory interface <NUM>, and a PCI Express (PCIe) block <NUM>, all coupled to each other and to the processing elements <NUM>, <NUM>, <NUM>, and <NUM> via a system/memory (sys/mem) NoC <NUM>. The PCIe block <NUM> is an interface used by the inference accelerator <NUM> to receive the inputs for inferences (e.g., images, videos, audio clips, or other data tensors) received by the host server and to provide results back to the host server. The system-on-chip <NUM> further comprises a management controller <NUM>, which is coupled to the PCIe block <NUM>, the memory controllers <NUM>, <NUM>, <NUM>, and <NUM>, and the processing elements <NUM>, <NUM>, <NUM>, and <NUM> via the system/memory NoC <NUM>. Note that, in some implementations, the compute network <NUM> may also connect to the PCIe block <NUM> and/or the memory controllers <NUM>, <NUM>, <NUM>, and <NUM>.

Further, a global synchronization manager (GSM) module <NUM> is coupled to the PCIe block <NUM> and a local sync manager (see <FIG>) in each processing element <NUM>, <NUM>, <NUM>, and <NUM> via a private NoC <NUM>. It should be noted that in alternative implementations, one or more of the compute NoC <NUM>, sys/mem NoC , and private NoC <NUM> may be replaced by a corresponding simple bus, or other communication fabric, other than a NoC. It should be further noted that some alternative implementations of the inference accelerator <NUM> do not include a private NoC and, instead, the GSM <NUM> communicates with other elements (e.g., the processing elements <NUM>, <NUM>, <NUM>, and <NUM>) via other means (e.g., sys/mem NoC <NUM>).

The processing elements <NUM>, <NUM>, <NUM>, and <NUM> may be neural processing units (NPUs), neural signal processors (NSPs), digital signal processors (DSPs), or any other suitable type of processor (e.g., CPUs or GPUs). In some homogenous embodiments (where the processing elements <NUM>, <NUM>, <NUM>, and <NUM> are substantially the same) each of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may include scalar, vector, matrix processing capabilities (e.g., multiplication, convolution, point-wise addition, point-wise multiplication), and data-movement capabilities (e.g., load, store, and direct memory access (DMA)). In some alternative embodiments, the scalar, vector, matrix, and data-movement processing capabilities may be distributed across different processing elements (in other words, the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may be heterogeneous). Additionally, whichever of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> provide matrix processing capabilities may further include floating point capabilities as part of the matrix processing capabilities. Providing these capabilities in each of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may enable a compiler for the inference accelerator <NUM> to more efficiently schedule code on the individual processing elements, as will be explained in greater detail with respect to <FIG>.

<FIG> is a simplified schematic diagram of an exemplary implementation of the processing element <NUM> of <FIG>. As noted above, in some embodiments, processing elements <NUM>, <NUM>, and <NUM> may be configured identically. The processing element <NUM> comprises tightly-coupled memory (TCM) <NUM>, vector processing module <NUM>, matrix processing module <NUM>, scalar processing (e.g., DSP) module <NUM>, memory processing module <NUM>, and an optional local synchronization manager (LSM) <NUM>. The TCM <NUM> is directly connected to at least the vector processing module <NUM>, the matrix processing module <NUM>, and the memory processing module <NUM>. The LSM <NUM> is directly connected to at least the scalar processing module <NUM>. The processing element <NUM> is connected to NoCs <NUM>, <NUM>, and <NUM>.

In some implementations, each LSM <NUM> of a processing element is connected to the GSM <NUM> of <FIG>, where the processing elements <NUM>, <NUM>, <NUM>, and <NUM> implement hardware memory synchronization using LSM <NUM> working with GSM <NUM> to coordinate and synchronize data transfers among the processing elements <NUM>, <NUM>, <NUM>, and <NUM> and the DRAMs <NUM> and <NUM>, by setting and resetting semaphores that allow or prohibit corresponding data operations. In this implementation, the LSM <NUM> may be referred to as a synchronization module. In some implementations, the GSM <NUM> works directly with the TCMs <NUM> of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> (forgoing LSMs <NUM>) to set and reset values at known locations in the TCMs <NUM>, where those values similarly allow or prohibit corresponding data operations. In this implementation, the TCM <NUM> may be referred to as a synchronization module.

The processing element <NUM> may forgo implementing a memory coherency protocol. Implementing a memory coherency protocol typically includes having a shared cache connected to a plurality of clients and an interconnecting bus with a coherency protocol to ensure that each client is referencing the latest version of corresponding data. Using caches and implementing a coherency protocol are useful when data movement and sharing is not sequential and not deterministic - in other words, what is conventionally referred to as "random. " Caches and coherency are also useful where data movements and sharing are relatively fine-grained. Semaphores, on the other hand, use the setting and modifying of so-called semaphores to gate data movement among a plurality of clients and gate computations involving the data - without using a cache or a bus implementing a coherency protocol. Neural-network inferencing involves large movements of data, and calculations based on that data, whose pattern is known ahead of time. Consequently, the integrity of that data may be maintained using a relatively simple semaphore mechanism. Since implementing memory coherency protocols requires relatively significant power levels, substituting hardware synchronization for coherency allows the inference accelerator <NUM> to maintain the needed level of memory synchronization at a relatively reduced power level.

Returning to <FIG>, the compute network <NUM> coupling the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may be a relatively higher-bandwidth network (as compared to the sys/mem network <NUM> and the private network <NUM>), and supports multicast operations (i.e., sending data produced by a single processing element to multiple other processing elements of the inference accelerator <NUM>). The processing elements <NUM>, <NUM>, <NUM>, and <NUM> may each include tightly-coupled memory (e.g. TCM <NUM> of <FIG>), and interact with the first DRAM <NUM> and the second DRAM <NUM> via the sys/mem network <NUM> and the memory controllers <NUM>, <NUM>, <NUM>, and <NUM>. Both the compute network <NUM> and the sys/mem network <NUM> may support DMA operations from the TCMs (e.g. TCM <NUM>) of each of the processing elements <NUM>, <NUM>, <NUM>, and <NUM>, including read operations, write operations, and, in the case of the compute network <NUM>, multicast operations.

The private network <NUM> may be a relatively slower and lower-bandwidth network (as compared to the compute network <NUM> and the sys/mem network <NUM>), as its use may be limited to a configuration time (as opposed to run time) and, thus, would not have a specific performance requirement (as opposed to the compute network <NUM> and the sys/mem network <NUM>). Having separate networks for these specific purposes allows each of the networks to be designed to match its corresponding expected traffic type and allows each to be individually performance and power optimized to match.

For example, since the workloads handled by the inference accelerator <NUM> may often involve data words that are all zeros (but that must still be transmitted among the processing elements <NUM>, <NUM>, <NUM>, and <NUM>), the compute network <NUM> may implement a "zero" encoding protocol, where setting a single override bit on the network bus indicates that the value of the corresponding data word is zero, without having to actually set all the bits of the data bus for that data word to zero or read all of the corresponding bits of the data word. This may reduce power usage both directly and by allowing for the implementation of power-saving operations based on the override bit.

Further, as indicated above, the inference accelerator <NUM> does not implement a memory coherency protocol, instead managing dependencies that do occur using hardware semaphores and compiler design (as explained later with respect to <FIG>) in accordance with the global sync manager <NUM>, which is configured to interact with the processing elements <NUM>, <NUM>, <NUM>, and <NUM> to provide hardware semaphore support. Essentially, each of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may set semaphores in the global sync manager <NUM>, which may be cleared by the other processing elements <NUM>, <NUM>, <NUM>, and <NUM> to allow for interdependencies in workloads being processing by the processing elements <NUM>, <NUM>, <NUM>, and <NUM>.

The latency involved in communications between the processing elements <NUM>, <NUM>, <NUM>, and <NUM> and the global sync manager <NUM> may be important for the overall performance of the inference accelerator <NUM>. Thus, the topology of the private network <NUM> providing connectivity between the global sync manager <NUM> and the processing elements <NUM>, <NUM>, <NUM>, and <NUM> may depend on the relative number of processing elements that will be coupled to the global sync manager <NUM>. In systems with relatively few processing elements, a ring topology may be used instead of the network <NUM> shown. In systems with larger numbers of processing elements, a star topology may be used. Those having skill in the art will recognize that the choice of topology may be informed by many factors involved in the overall system design, and the teachings of the present disclosure do not depend on the use of a particular topology.

<FIG> is a hybrid schematic and flow diagram <NUM> for exemplary operation of a compiler which may be configured to schedule operations on inference accelerator <NUM> of <FIG>. A neural network description <NUM> is provided to the compiler, which, in a first phase, transforms, in step <NUM>, the neural network description <NUM> into a form that may be represented by directed acyclic graph <NUM>. A directed acyclic graph is a graph that has forward progress, without loopbacks, among its nodes (e.g., a tree structure progressing from the trunk to the leaves). The graph <NUM> comprises a plurality of tasks represented by graph nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Graph <NUM> shows that task <NUM> must be performed first, and then task <NUM>, but then any of tasks <NUM>, <NUM>, and <NUM> may be performed. In addition, graph <NUM> shows that both tasks <NUM> and <NUM> have to be completed before task <NUM> can be executed (in other words, task <NUM> is dependent on tasks <NUM> and <NUM>). Similarly, task <NUM> is dependent on tasks <NUM> and <NUM>.

In a second phase, in step <NUM>, the compiler converts the tasks <NUM>-<NUM>, shown in graph <NUM>, into command lists <NUM>, <NUM>, <NUM>, and <NUM> and schedules them for processing on corresponding hardware processing elements such as scalar, vector, matrix, and data movement blocks of the processing elements <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>. In other words, command lists <NUM>, <NUM>, <NUM>, and <NUM> may correspond, respectively, to vector processing module <NUM>, matrix processing module <NUM>, scalar processing module <NUM>, and memory processing module <NUM> of <FIG>. The scheduling may be optimized for factors such as, for example, time, power, or resource requirements.

The compiler may be optimized for use with neural networks, and thus it may generate "static" workloads. Specifically, since branching and iteration counts may be known ahead of time, they may be used to generate static workloads, as opposed to, for example, conventional CPU or GPU code, which may have unpredictable branching behavior and iteration counts and, consequently, would require generating dynamic workloads. Because these workloads are static, the command lists generated by the compiler may permit workload balancing in the computing device <NUM> by dispatching a portion of a total workload to be executed to the computing device <NUM> after which the computing device <NUM> may wait (and may possibly even enter a low-power state) for further instructions. This workload distribution and balancing is referred to herein as "dispatch scaling. " Note that, in generating parallel workloads, the compiler may direct the replication of data sets between processing elements, where the replication may be performed using the multicast capabilities of the compute network <NUM>.

The above is possible because, since the workload is static, dispatching one-fourth of a total workload (e.g., one fourth of the total operations), for example, will result in the one-fourth of the total workload being completed. This contrasts with a conventional CPU/GPU workload, in which it may be essentially impossible to predict ahead of time how much of a total workload may be completed by providing one-fourth of the workload to the computing device, and thus, in order to save power, conventional methods such a frequency and voltage scaling may be used. Further, instead of generating command lists, which would conventionally be interpreted by software running on the processing elements <NUM>, <NUM>, <NUM>, and <NUM>, the compiler may alternatively generate static code which is executed in sequence. Dispatch scaling may be used in either case (command lists or statically generated code).

Although the compiler attempts to generate command lists that are fully parallelizable and do not have interdependencies, sometimes this may not be feasible. In cases where interdependencies exist, since the computing device <NUM> does not implement coherency, the compiler will insert a synchronization indicator (e.g., a semaphore) that is mapped to a hardware semaphore resource. Different processing elements may interact, via, e.g., GSM <NUM>, using the semaphore to guarantee that dependencies are satisfied. The compiler may schedule tasks to command lists based on optimistic estimated completion times and the semaphores may be relied on to guarantee that dependencies are satisfied where actual completion times exceed the estimated completion times.

Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the aspects disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer readable medium and executed by a processor or other processing device, or combinations of both. The devices described herein may be employed in any circuit, hardware component, IC, or IC chip, as examples. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends upon the particular application, design choices, and/or design constraints imposed on the overall system.

The aspects disclosed herein may be embodied in hardware and in instructions or design data that are stored in hardware, and may reside, for example, in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer readable medium known in the art. In the case of design data, the data may be an electronic representation of a physical design of a circuit, may be readable by integrated circuit fabrication equipment, and may be in a file format such as GDSII, GERBER, or the like.

It is also noted that the operational steps described in any of the exemplary aspects herein are described to provide examples and discussion. Additionally, one or more operational steps discussed in the exemplary aspects may be combined. It is to be understood that the operational steps illustrated in the flowchart diagrams may be subject to numerous different modifications as will be readily apparent to one of skill in the art. Those of skill in the art will also understand that information and signals may be represented using any of a variety of different technologies and techniques.

Claim 1:
An inference accelerator (<NUM>) comprising:
a memory system (<NUM>, <NUM>, <NUM>, <NUM>);
a plurality of processing elements (<NUM>, <NUM>, <NUM>, <NUM>), each processing element:
having a tightly coupled memory (<NUM>), TCM;
coupled to the memory system; and
adapted to access the memory system;
a global synchronization manager (<NUM>), GSM, module coupled to the plurality of processing elements and to the memory system, the GSM adapted to synchronize operations of the plurality of processing elements and memory system using corresponding synchronization modules of each of the plurality of processing elements;
a second network (<NUM>) connecting each of the plurality of processing elements to the memory system,
characterised in further comprising:
a first network (<NUM>) interconnecting the plurality of processing elements and the first network configured to support multicast operations,
wherein the second network (<NUM>) is separate from the first network.