Patent Description:
A machine-learning accelerator is an application-specific integrated circuit (ASIC) that is designed for performing highly parallel synchronous operations. The parallelism is achieved by integrating many different independent processing elements that can execute concurrently.

Such devices can be used to accelerate inference passes through neural networks. Neural networks are machine learning models that employ multiple layers of operations to predict one or more outputs from one or more inputs. Neural networks typically include one or more hidden layers situated between an input layer and an output layer. The output of each layer is used as input to another layer in the network, e.g., the next hidden layer or the output layer.

Typically, the computational operations required for each layer require many multiplyaccumulate (MAC) operations. In the usual case, each layer reads in activations computed by a previous layer, multiplies the activations by one or more layer-specific weights, and computes a sum of the multiplication results. In this specification, the term "activation" is used for inputs to the layers of a machine-learning accelerator because in real-world systems, the layers may operate on matrixes or tensors rather than individual values. For example, to perform a 3x3 convolution, each of <NUM> input activations can be multiplied by <NUM> respective weights, and the sum of the multiplies is a single output activation for the next layer.

Some accelerators use tiles and vector accumulators to implement MAC operations, with tiles being used to multiply activations by weights, and vector accumulators being used to sum the results and to apply other layer transformations to the result. In this specification, a tile refers to a device having a computational array of cells that can perform computations on a portion of a matrix or tensor. Each cell thus includes circuitry that allows the cell to perform mathematical or other computations. In a typical scenario, a tile receives an input tensor, uses the computational array of cells to multiply the input tensor by a weight tensor, and generates an output tensor. In the examples below, single variables will often be used for simplicity and clarity, but in real applications, each single variable can represent a higher-dimensional tensor and not just a singular numerical value.

The benefits are massive parallelism can be severely blunted by bad hardware utilization. Hardware utilization is a measure that quantifies the fraction of hardware devices that are used over any particular time period. Hardware utilization can be expressed using any appropriate metric, e.g., the fraction or percentage of tiles that are used for a particular layer.

Accelerator scheduling is the process by which layer operations are assigned to actual hardware devices to be performed at particular times. The general problem involves assigning portions of an input activation rectangle to portions of an array of tiles at particular points in time. In this specification, an activation rectangle is an array of input data. Each element of the activation rectangle includes activation data. For brevity each element of an activation rectangle may be referred to as a pixel, although as described above a pixel is a tensor having multiple, and potentially many, features rather than being a single value.

<FIG> illustrates the basic problem of scheduling for a machine learning accelerator. An activation rectangle <NUM> has N rows and M columns. In this case, N is <NUM> and M is <NUM>. Each pixel within the activation rectangle has <NUM> associated features, which are indicated by the <NUM> in the activation rectangle <NUM>.

The accelerator hardware <NUM> is an array of tiles, which generally also has rows and columns. In this specification, a column of tiles is a group of tiles that output data in parallel to a vector accumulator. Thus, if an accelerator has N rows and M columns, the accelerator can perform up to M MAC operations in parallel, with each MAC operation using computations from up to N tiles.

One prior art technique for accelerator scheduling involves distributing activations along columns and activation features along rows of the tile array. However, the utilization for this scheduling technique depends heavily on how closely the number of features matches the number of columns. If the activation data has <NUM> features and the accelerator has <NUM> columns, the utilization would only be <NUM>%.

To increase the utilization, the accelerator could use a technique known as least column multiple scheduling by filling up the unused columns with additional activation features. However, this technique suffers from major drawbacks. The first is that there is no weight reuse, meaning that on every cycle uses a different feature and thus every tile has to use a different weight. In addition, there is no activation locality between layers, meaning that the output computed from one layer will not match the required location to be used as input for the next layer. Therefore, in practice, this technique requires performing a highly complex and expensive reshuffle of all the data on the chip between layers.

"DaDianNao: A Machine-Learning Supercomputer" (<NPL>) discloses a custom multi-chip machine-learning architecture using on chip storage of the multi-chip system. When combined with the CNN/DNN algorithmic characteristics, this can lead to high internal bandwidth and low external communications, which can in turn enable high-degree parallelism at a reasonable area cost.

<CIT>discloses a convolutional computation accelerator, a convolutional computation method, and a convolutional computation device and relate to the technical field of electronic circuits. The convolutional computation accelerator comprises: a controller, a computation matrix, and a first cache. The computation matrix comprises at least one row of computation units, each row of computation units comprise at least two computation units, and adjacent two computation units in each row of computation units are connected with each other. The controller is used for controlling the loading of input data of each row of computation units into the first cache and the inputting of the input data loaded into the first cache to the corresponding row of computation units, so that the corresponding row of computation units transmit the input data in the corresponding row of computation units. Each computation unit of the corresponding row of computation units performs a convolutional computation on the received input data with a prestored convolution kernel.

<CIT> discloses techniques for performing neural network computations. In one embodiment, an apparatus may include an array of processing elements, the array having a configurable first effective dimension and a configurable second effective dimension. The apparatus may also include a controller configured to determine at least one of: a first number of input data sets to be provided to the array at the first time or a second number of output data sets to be generated by the array at the second time, and to configure, based on at least one of the first number or the second number, at least one of the first effective dimension or the second effective dimension of the array.

Further aspects and examples are provided for facilitating the understanding of the invention.

This specification describes a machine learning accelerator that uses topological scheduling. With topological scheduling, the columns of the tile array are partitioned into wide columns, and the columns of the input activation rectangle are also partitioned into an equal number of wide columns. In this specification, a wide column is a group of two or more columns of a tile array or an activation rectangle. These two types of wide columns can thus be referred to as a either a tile wide column, for wide columns in the tile array; or a pixel wide column, for wide columns in the activation rectangle.

Topological scheduling then binds the tile wide columns and the pixel wide columns such that pixels belonging to one pixel wide column are processed by tiles in a corresponding tile wide column. Topological scheduling also distributes features of each pixel along the columns of a single column in the tile wide columns.

Using topological scheduling increases hardware utilization of grid-based machine-learning accelerators compared to prior art scheduling approaches. This reduces system latency and improves overall processing speed. Using topological scheduling also reduces conveyor bandwidth that is required to shuffle data within the device and obviates the need to perform complex reshuffling of data between layers of a machine learning model. The topological scheduling techniques also allow input activations to be read once and then shared among tiles along the same row of a wide column within a subrectangle of the entire grid, which reduces the data input latency and increases the overall effective data transfer bandwidth of the hardware.

<FIG> illustrates a high-level view of the assignments of an example topological schedule. In this example, the activation rectangle <NUM> is logically partitioned into a plurality of pixel wide columns, here four pixel wide columns PWC0 through PWC3. Likewise, the accelerator hardware <NUM> is logically partitioned into a corresponding plurality of tile wide columns, here four tile wide columns TWC0 through TWC3. In <FIG>, it can be seen that maintaining the correspondence between pixel wide columns and tile wide columns results in the assignment of difference features from row <NUM> of the activation rectangle to tiles in the accelerator hardware <NUM>.

In this example, the eight features F0. F7 of pixel <NUM> have been assigned respectively to the tiles belonging to the 0th column of TWC0, the eight features F0. F7 of pixel <NUM> have been assigned respectively to the tiles belonging to the 1st column of TWC0, and so on.

The example in <FIG> illustrates an advantage of topological scheduling, which is that tiles having the same features are physically close to each other, which facilitates weight reuse. For example, tiles all along the top row of the accelerator hardware <NUM> all use the same weight for feature F0. Thus, much less data shuffling is required, which is a major advantage over least column multiple scheduling described above.

TABLES <NUM> and <NUM> illustrate another example of partitioning a tile array and a single row of an activation rectangle to have corresponding wide columns. This is an example in which the width of the tile wide columns and the width of the pixel wide columns are different.

In TABLE <NUM>, TWC represents an index of a tile wide column, and Lng represents a chip longitude of a tile column in a chip having <NUM> tile columns.

In other words, the assignments in TABLE indicate that the tile columns of the accelerator have been divided into <NUM> wide columns. A topological schedule will then assign wide columns of the activation rectangle to respective wide columns of the tile array.

In TABLE <NUM>, PWC represents an index of a pixel wide column, and represents a width location of a pixel in the activation rectangle:
<IMG>.

Thus, each tile wide column is assigned <NUM> pixels each. The pixels assigned to each tile wide column will be processed sequentially in time at a time step represented by tW.

<FIG> is a diagram illustrating more hardware detail for implementing topological scheduling. <FIG> illustrates the hardware structures and data movements that are involved in a single tile wide column of a tile array.

<FIG> illustrates a single, tile wide column having four tile columns, with each column of tiles having four rows. Thus, a Oth column <NUM> includes tiles <NUM>, <NUM>, <NUM>, and <NUM>; a 1st column <NUM> includes tiles <NUM>, <NUM>, <NUM>, and <NUM>; a 2nd column <NUM> includes tiles <NUM>, <NUM>, <NUM>, and <NUM>; and a 3rd column <NUM> includes tiles <NUM>, <NUM>, <NUM>, and <NUM>. Each tile column also includes a respective vector accumulator, e.g., a vector accumulator <NUM> for the Oth column <NUM>, a vector accumulator <NUM> for the 1st column <NUM>, a vector accumulator <NUM> for the 2nd column <NUM>, and a vector accumulator <NUM> for the 3rd column <NUM>. Real-world implementations can have more than <NUM> rows and/or more than <NUM> columns per wide column.

In operation, the features of the activation rectangle are distributed along tiles of a single tile column. Thus, for example, if each pixel has four features, these four features can be assigned respectively to tiles <NUM>, <NUM>, <NUM>, and <NUM>. If a pixel has more features than the number of rows in a tile column, the accelerator can compute the extra features on subsequent time steps. In this specification, a time step is any appropriate time period required for a device to compute layer operations for an input pixel. For example, each time step can be a time period required for the tiles in a column to compute their multiplications and for a corresponding vector accumulator to sum the results, apply one or more transformations to the result, and write the result to an output RAM. A time step can thus include one or more clock cycles.

At each time step, tiles in a single column perform a multiplication of an input activation by a respective weight for a respective feature. The results are then passed to a vector accumulator for the tile column. Thus, for example, the vector accumulator <NUM> receives multiplication results for tiles <NUM>, <NUM>, <NUM>, and <NUM>. In <FIG>, all inputs along a column into the vector accumulator should be interpreted as originating from a respective tile and then bypassing all other tiles and RAMs. For illustrative ease, the lines representing such data movements have been illustrated behind these other devices. In a real-world implementation, these devices would not receive or manipulate the inputs to the vector accumulators.

The vector accumulator <NUM> then writes the result to an output RAM <NUM> situated at a location in the tile array having the following properties: the output RAM is in the same column as the vector accumulator and in the row at which it will be read on a subsequent layer of the network. In this example, the computations for the next layer will be read by tiles in the Oth row <NUM>, and thus, the vector accumulator <NUM> writes the results to the output RAM <NUM> located on the Oth row <NUM>.

In this context, a RAM being situated at a particular location in the tile array means that a tile at that location can read from the RAM without using conveyors. In this specification, conveyors are hardware connection devices that communicate data from one area to another on the physical accelerator. Conveyors typically require one or more time steps in order to effectuate the data transmission. But in this example, the tile <NUM> can read from the output RAM <NUM> without using conveyors, and therefore, the output RAM <NUM> is considered to be at the same location as the tile <NUM> for the purposes of topological scheduling. In other words, the logical boundaries of rows and columns in the tile array are defined by which elements need to use conveyors to communicate data.

As illustrated in <FIG>, the operations of the topological schedule result in a diagonal pattern of input RAMs and output RAMs. This pattern emerges due to the dimensions of the device and the wide columns and the number of features in the input activations. <FIG> illustrates only those devices that contribute to the output for a single, wide column. But in a real-world implementation, an accelerator can actually have input RAMs and output RAMs at every location. In some implementations, at one or more of the locations, these input and output RAMs can actually be the same memory device.

On the next time step, the tiles in the 1st column <NUM> can compute their multiplications using their respective weights and features. This example illustrates one of the technological advantages of using topological scheduling, which is that tiles along a row of a wide column can share input activations. As illustrated in <FIG>, the tile <NUM> in the Oth column <NUM> reads from the input RAM <NUM>, and on the next time step, the tile <NUM> in the 1st column <NUM> reads the same input activation from the tile <NUM>.

This means that the accelerator needs to load the input activation into the input RAM <NUM> only once, and then the input activation is shared with all other tiles in a row using the conveyor hardware. This design reduces the data bandwidth and memory latency compared to approaches that require reading input activations on every time step. In addition, the physical communication distance required for sharing of the input activations is small. As shown in <FIG>, the tiles generally share input activations with a physically adjacent tile in the tile array.

Topological scheduling also improves activation locality compared to prior art approaches. In other words, storing the computation results at a row at which they will be consumed on the next layer reduces the need for full performing a full-chip reshuffle as described above regarding least column multiple scheduling. Thus, the usage of the conveyor hardware between layers is greatly reduced, which makes overall processing faster.

Because of this technique of storing output data at a row at which it will be used at a next layer, on some time steps it is necessary use the conveyor hardware to move the input activation over to the Oth column <NUM> before beginning computation. Thus, for example, the input activation in the input RAM <NUM> can be moved left in the time step before computation begins for the Oth column <NUM>. All of these data movements can be prescheduled by the compiler for the accelerator so that all data movements precede all column-wise computations. Input RAMs that are stored farther away from the Oth column <NUM> may need to be moved farther distance, which may require additional time steps. For example, the input activation stored in the input RAM <NUM> needs to move three steps to the left before being used by the tile <NUM> in the Oth column <NUM>. All of these precomputation data movements can be prescheduled by the compiler.

In order to support convolutions larger than 1x1, the accelerator can have additional conveyors that communicate the edges of the wide columns to adjacent wide columns whenever they are computed. For example, whenever a value is stored to the output RAM <NUM>, the system can automatically propagate those output values to output RAMs located in one or both adjacent wide columns.

<FIG> is a flowchart of an example process for executing a topological schedule. The process will be described as being performed by a system having a tile array, e.g., a machine learning accelerator, partitioned into tile wide columns.

The system reads input activations from an input RAM (<NUM>). The input activations can be computed from a previous layer of a neural network and stored in the input RAM. The input activations can be computed by the same device or a different device. For example, a machine learning accelerator may have multiple arrays of tiles that compute different portions of layer operations.

The system aligns input activations with an edge of each tile wide column (<NUM>). As described above, the system can use conveyor hardware to move the input activation from the input RAM where it is stored to a same edge of each tile wide column. Some alignment operations may take longer than others, so they system can wait until all input activations are aligned at the same edge of the tile wide column.

The system selects a next index value within each tile wide column (<NUM>). As described above, within each tile wide column, the system iterates over each tile column on each time step.

The system computes, in parallel, output values from tiles within each tile wide column having the selected index value (<NUM>). For example, if the index value is <NUM>, the device can process each Oth tile column within each fat column in parallel.

The system stores each output value in a same respective column and at a row from which it will be read on a subsequent layer (<NUM>). As described above, the system identifies an output RAM on the same column that the output value was computed and on a row from which the value will be read on a subsequent layer.

The system determines if there are more tile columns to process in each tile wide column (<NUM>). If so, the system selects a next index within each tile wide column (branch to <NUM>).

If not, the system determines whether there is more activation data to process (<NUM>). If so, the system returns to read the new activations from one or more input RAMs (branch to <NUM>). For example, the system can load input activations and feature values for other pixels from the activation rectangle until all data in the activation rectangle has been processed.

If all data has been processed, the process ends (branch to end).

<FIG> is a flowchart of an example process for generating a topological schedule. The example process can be performed by a compiler installed on any appropriate computing system having one or more computers in one or more locations. For convenience, the example process will be described as being performed by a system of one or more computers.

The system receives an input program having an activation rectangle to be executed on an accelerator having a tile array (<NUM>). As described above, the input program can define the architecture and operations of a neural network having multiple layers.

The system splits the activation rectangle and the tile array into wide columns and associates each tile wide column with a corresponding pixel wide column (<NUM>). For example, the system can split both the activation rectangle and the tile array into an equal number of wide columns. In general, the wideness of a column is two or greater less than half of the width of either the activation rectangle or the tile array. The "wideness" of each wide column is a parameter that can be chosen to optimize performance. Choosing smaller wideness values increases the throughput of the chip, but also requires store more copies of weights, more padding of the activation rectangle, and reduced read activation sharing between tiles.

The system schedules operations to be performed in multiple wide columns in parallel (<NUM>). As described above, at each time step the system computes operations for a single tile column within each of the wide columns. Thus, the system can preschedule all of these operations according to the wide columns of the tile array. It is quite common to require multiple passes through a tile array in order to compute all the data from the activations. For example, as illustrated in <FIG>, the tile array in that example was able to compute only a single row from the activation rectangle. Thus, the system can schedule additional operations in order to process subsequent portions of the activation rectangle. In some implementations, the number of features may exceed the number of rows of the tile array. In that situation, the system can add additional inner loops so that multiple time steps are used to process all the features of each input pixel.

The above description of scheduling can be formalized into the following constraints that can be used by a compiler in order to assign layer operations to tiles.

In some implementations, a machine learning accelerator can be partitioned into multiple independent partitions. In that case, the system can impose additional constraints on the scheduling process that essentially state that partitions cannot change when computing results adhering to a topological schedule. In addition, some machine learning accelerator columns are actually super columns having multiple internal tile columns. In those devices, the system can also impose additional constraints on the index of the internal tile columns.

<FIG> is a schematic that illustrates an example of special purpose logic circuitry, in particular, an ASIC <NUM>. The ASIC <NUM> includes multiple synchronous processors that for brevity will be referred to as tiles. For example, the ASIC <NUM> includes tiles <NUM>, in which one or more of the tiles <NUM> includes special purpose circuitry configured to perform synchronous computations, such as e.g., multiplication and addition operations. In particular, each tile <NUM> can include a computational array of cells, in which each cell is configured to perform mathematical operations (see, e.g., the exemplary tile <NUM> shown in <FIG>, and described herein). In some implementations, the tiles <NUM> are arranged in a grid pattern, with tiles <NUM> arranged along a first dimension <NUM> (e.g., rows) and along a second dimension <NUM> (e.g., columns). For instance, in the example shown in <FIG>, the tiles <NUM> are divided into four different sections (510a, 510b, 510c, 510d), each section containing <NUM> tiles arranged in a grid of <NUM> tiles down by <NUM> tiles across. In some implementations, the ASIC <NUM> shown in <FIG> may be understood as including a single systolic array of cells subdivided/arranged into separate tiles, in which each tile includes a subset/sub-array of cells, local memory and bus lines (see, e.g., <FIG>).

The ASIC <NUM> also includes a vector processing unit <NUM>. The vector processing unit <NUM> includes circuitry configured to receive outputs from the tiles <NUM> and compute vector computation output values based on the outputs received from the tiles <NUM>. For example, in some implementations, the vector processing unit <NUM> includes circuitry (e.g., multiply circuitry, adder circuitry, shifters, and/or memory) configured to perform accumulation operations on the outputs received from the tiles <NUM>. Alternatively, or in addition, the vector processing unit <NUM> includes circuitry configured to apply a non-linear function to the outputs of the tiles <NUM>. Alternatively, or in addition, the vector processing unit <NUM> generates normalized values, pooled values, or both. The vector computation outputs of the vector processing units can be stored in one or more tiles. For example, the vector computation outputs can be stored in memory uniquely associated with a tile <NUM>. Alternatively, or in addition, the vector computation outputs of the vector processing unit <NUM> can be transferred to a circuit external to the ASIC <NUM>, e.g., as an output of a computation. In some implementations, the vector processing unit <NUM> is segmented, such that each segment includes circuitry configured to receive outputs from a corresponding collection of tiles <NUM> and computes vector computation outputs based on the received outputs. For instance, in the example shown in <FIG>, the vector processing unit <NUM> includes two rows spanning along the first dimension <NUM>, each of the rows including <NUM> segments <NUM> arranged in <NUM> columns. Each segment <NUM> includes circuitry (e.g., multiply circuitry, adder circuitry, shifters, and/or memory) configured to perform a vector computation, as explained herein, based on outputs (e.g., an accumulated sum) from a corresponding column of tiles <NUM>. The vector processing unit <NUM> can be positioned in the middle of the grid of tiles <NUM> as shown in <FIG>. Other positional arrangements of the vector processing unit <NUM> are also possible.

The ASIC <NUM> also includes a communication interface <NUM> (e.g., interfaces 508a, 508b). The communication interface <NUM> includes one or more sets of serializer/deserializer (SerDes) interfaces and a general purpose input/output (GPIO) interface. The SerDes interface is configured to receive instructions (e.g., instructions for operating controllable bus lines described below) and/or input data for the ASIC <NUM> and to output data from the ASIC <NUM> to an external circuit. For example, the SerDes interface can be configured to transmit instructions and/or input data at a rate of <NUM> Gbps, <NUM> Gbps, or any suitable data rate over the set of SerDes interfaces included within the communications interface <NUM>. The GPIO interface is configured to provide an interface for debugging and/or bootstrapping. For example, the ASIC <NUM> may run a boot program when it is turned on. If the program fails, an administrator may use the GPIO interface to debug the source of the failure.

The ASIC <NUM> further includes multiple controllable bus lines (see, e.g., <FIG>) configured to convey data among the communications interface <NUM>, the vector processing unit <NUM>, and the multiple tiles <NUM>. Controllable bus lines include, e.g., wires that extend along both the first dimension <NUM> (e.g., rows) of the grid and the second dimension <NUM> (e.g., columns) of the grid. A first subset of the controllable bus lines extending along the first dimension <NUM> can be configured to transfer data in a first direction (e.g., to the right of <FIG>). A second subset of the controllable bus lines extending along the first dimension <NUM> can be configured to transfer data in a second direction (e.g., to the left of <FIG>). A first subset of the controllable bus lines extending along the second dimension <NUM> can be configured to transfer data in a third direction (e.g., to the top of <FIG>). A second subset of the controllable bus lines extending along the second dimension <NUM> can be configured to transfer data in a fourth direction (e.g., to the bottom of <FIG>).

Each controllable bus line includes multiple conveyer elements, such as flip-flops, that are used to convey data along the lines in accordance with a clock signal. Transferring data over a controllable bus line can include shifting, at each clock cycle, data from a first conveyer element of the controllable bus line to a second adjacent conveyer element of the controllable bus line. In some implementations, data is conveyed over the controllable bus lines upon the rising or falling edge of a clock cycle. For example, data present, at a first clock cycle, on a first conveyer element (e.g., a flip-flop) of a controllable bus line can be transferred to a second conveyer element (e.g., a flip-flop) of the controllable bus line at a second clock cycle. In some implementations, the conveyer elements can be periodically spaced apart at a fixed distance from one another. For example, in some cases, each controllable bus line includes multiple conveyer elements, with each conveyer element positioned within or proximate to a corresponding tile <NUM>.

Each controllable bus line also includes multiple multiplexers and/or demultiplexers. A multiplexer/demultiplexer of a controllable bus line is configured to transfer data between the bus line and a component of the ASIC chip <NUM>. For example, a multiplexer/demultiplexer of a controllable bus line can be configured to transfer data to and/or from a tile <NUM>, to and/or from the vector processing unit <NUM>, or to and/or from the communication interface <NUM>. Transferring data among tiles <NUM>, the vector processing unit <NUM>, and the communication interface can include sending control signals to the multiplexers based on the desired data transfer to take place. The control signals can be stored in registers coupled directly to the multiplexer and/or demultiplexers. The value of the control signal then may determine, e.g., what data is transferred from a source (e.g., memory within a tile <NUM> or a vector processing unit <NUM>) to a controllable bus line or, alternatively, what data is transferred from the controllable bus line to a sink (e.g., memory within a tile <NUM> or a vector processing unit <NUM>).

The controllable bus lines are configured to be controlled on a local level, such that each tile, vector processing unit, and/or communication interface includes its own set of control elements for manipulating the controllable bus lines passing through that tile, vector processing unit, and/or communication interface. For example, each tile, 1D vector processing unit, and communication interface may include a corresponding set of conveyer elements, multiplexers and/or demultiplexers for controlling data transfer to and from that tile, 1D vector processing unit, and communication interface.

To minimize latency associated with operations of the ASIC chip <NUM>, the tiles <NUM> and vector processing unit <NUM> can be positioned to reduce the distance data travels among the various components. In a particular implementation, both the tiles <NUM> and communication interface <NUM> can be segregated into multiple sections, with both the tile sections and the communication interface sections being arranged such that the maximum distance data travels between a tile and a communication interface is reduced. For instance, in some implementations, a first group of tiles <NUM> can be arranged in a first section on a first side of the communications interface <NUM>, and a second group of tiles <NUM> can be arranged in a second section on a second side of the communication interface. As a result, the distance from a communication interface to the furthest tile may be cut in half compared to a configuration in which all of the tiles <NUM> are arranged in a single section on one side of the communication interface.

Alternatively, the tiles may be arranged in a different number of sections, such as four sections. For instance, in the example shown in <FIG>, the multiple tiles <NUM> of ASIC <NUM> are arranged in multiple sections <NUM> (510a, 510b, 510c, 510d). Each section <NUM> includes a similar number of tiles <NUM> arranged in a grid pattern (e.g., each section <NUM> can include <NUM> tiles arranged in <NUM> rows and <NUM> columns). The communication interface <NUM> also is divided into multiple sections: a first communication interface 508a and a second communication interface 508b arranged on either side of the sections <NUM> of tiles <NUM>. The first communication interface 508a can be coupled, through controllable bus lines, to the two tile sections 510a, 510c on the left side of the ASIC chip <NUM>. The second communication interface 508b can be coupled, through controllable bus lines, to the two tile sections 510b, 510d on the right side of the ASIC chip <NUM>. As a result, the maximum distance data travels (and thus the latency associated with the data propagation) to and/or from a communication interface <NUM> can be halved compared to an arrangement in which only a single communication interface is available. Other coupling arrangements of the tiles <NUM> and communication interfaces <NUM> are also possible to reduce data latency. The coupling arrangement of the tiles <NUM> and communication interface <NUM> can be programmed by providing control signals to the conveyer elements and multiplexers of the controllable bus lines.

In some implementations, one or more tiles <NUM> are configured to initiate reading and writing operations with respect to controllable bus lines and/or other tiles within the ASIC <NUM> (referred to herein as "control tiles"). The remaining tiles within the ASIC <NUM> can be configured to perform computations based on the input data (e.g., to compute layer inferences). In some implementations, the control tiles include the same components and configuration as the other tiles within the ASIC <NUM>. The control tiles can be added as an extra tile or tiles, an extra row or rows, or an extra column or columns of the ASIC <NUM>. For example, for a symmetric grid of tiles <NUM>, in which each tile <NUM> is configured to perform a computation on input data, one or more additional rows of control tiles can be included to handle reading and writing operations for the tiles <NUM> performing computations on the input data. For instance, each section <NUM> includes <NUM> rows of tiles, where the last two rows of tiles may include control tiles. Providing separate control tiles increases, in some implementations, the amount of memory available in the other tiles used to perform the computations. Separate tiles dedicated to providing control as described herein are not necessary, however, and in some cases, no separate control tiles are provided. Rather, each tile may store in its local memory instructions for initiating reading and writing operations for that tile.

Furthermore, while each section <NUM> shown in <FIG> includes tiles arranged in <NUM> rows by <NUM> columns, the number of tiles <NUM> and their arrangement in a section can be different. For example, in some cases, the sections <NUM> may include an equal number of rows and columns.

Furthermore, although shown in <FIG> as divided into four sections, the tiles <NUM> can be divided into other different groupings. For example, in some implementations, the tiles <NUM> are grouped into two different sections, such as a first section above the vector processing unit <NUM> (e.g., nearer the top of the page shown in <FIG>) and a second section below the vector processing unit <NUM> (e.g., nearer to the bottom of the page shown in <FIG>). In such an arrangement, each section may contain, e.g., <NUM> tiles arranged in a grid of <NUM> tiles down (along direction <NUM>) by <NUM> tiles across (along direction <NUM>). Sections may contain other total numbers of tiles and may be arranged in different sized arrays. In some cases, the divisions between sections are delineated by hardware features of the ASIC <NUM>. For example, as shown in <FIG>, sections 510a, 510b may be separated from sections 510c, 510d by the vector processing unit <NUM>.

Latency also may be reduced by centrally locating the vector processing unit <NUM> relative to the tile sections <NUM>. In some implementations, a first half of the tiles <NUM> are arranged on a first side of the vector processing unit <NUM>, and a second half of the tiles <NUM> are arranged on a second side of the vector processing unit <NUM>.

For example, in the ASIC chip <NUM> shown in <FIG>, the vector processing unit <NUM> includes two sections (e.g., two rows), each of which includes a number of segments <NUM> that matches the number of columns of tiles <NUM>. Each segment <NUM> can be positioned and configured to receive an output, such as an accumulated sum, from a corresponding column of tiles <NUM> within a section <NUM> of tiles. In the example shown in <FIG>, the tile sections 510a, 510b positioned on a first side of the vector processing unit <NUM> (e.g., above the vector processing unit <NUM>) can be coupled, through controllable bus lines, to the top row of segments <NUM>. The tile sections 510c, 510d positioned on a second side of the vector processing unit <NUM> (e.g., below the vector processing unit <NUM>) can be coupled, through controllable bus lines, to the bottom row of segments <NUM>. Furthermore, each tile <NUM> within the first half above the processing unit <NUM> can be positioned at a same distance from the vector processing unit <NUM> as a respective tile <NUM> within the second half below the processing unit <NUM>, such that there is no difference in overall latency between the two halves. For instance, the tiles <NUM> in row i in the first section 510a (where the variable i corresponds to the row position) can be positioned at the same distance away from vector processing unit <NUM> as the tiles <NUM> in row m-<NUM>-i in a second section of tiles (e.g., the section 510c) (where m represents the total number of rows in each section, and assuming rows are incremented along the same direction in both sections).

Configuring the tile sections <NUM> in this manner can halve the distance data travels (and thus the latency associated with the data propagation) to and/or from the vector processing unit <NUM> compared to an arrangement in which the vector processing unit <NUM> is positioned at a far end (e.g., the bottom) of all the tiles <NUM>. For instance, the latency associated with receiving an accumulated sum through a column of tiles <NUM> from section 510a can be half the latency associated with receiving an accumulated sum through a column of tiles <NUM> from sections 510a and 510c. The coupling arrangements of the tiles <NUM> and the vector processing unit <NUM> can be programmed by providing control signals to the conveyer elements and multiplexers of the controllable bus lines.

During operation of the ASIC chip <NUM>, activation inputs may be shifted between tiles. For example, activation inputs can be shifted along the first dimension <NUM>. In addition, outputs from computations performed by the tiles <NUM> (e.g., outputs of computations performed by computational array within the tile <NUM>) can be shifted along the second dimension <NUM> between tiles.

In some implementations, the controllable bus lines can be physically hardwired to cause data to skip tiles <NUM> to reduce latency associated with the operations of the ASIC chip <NUM>. For example, an output of a computation performed by a first tile <NUM> can be shifted along the second dimension <NUM> of the grid to a second tile <NUM> positioned at least one tile away from the first tile <NUM>, thus skipping the tile in between. In another example, an activation input from a first tile <NUM> can be shifted along the first dimension <NUM> of the grid to a second tile <NUM> positioned at least one tile away from the first tile <NUM>, thus skipping the tile in between. By skipping at least one tile when shifting the activation input or the output data, the overall data path length can be reduced, such that the data is transferred faster (e.g., there is no need to utilize a clock cycle to store data at the skipped tile), and latency is reduced.

In an example implementation, each tile <NUM> within each column of section 510a can be configured, through the controllable bus lines, to pass output data along the second dimension <NUM> toward the vector processing unit <NUM>. The tiles <NUM> within each column can be further configured to pass the data toward the vector processing unit <NUM> by skipping the next adjacent tile (e.g., through physical hardwiring of the controllable bus lines between tiles). That is, a tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a (where the variable i corresponds to the row position and the variable j corresponds to the column position) can be hardwired to pass output data to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>); similarly, the tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a can be hardwired to pass output data to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>), and so forth. The last tile that is not skipped (e.g., the tile <NUM> located at position (i, j) = (<NUM>, <NUM>)) passes output data to the vector processing unit <NUM>. For a section <NUM> having <NUM> rows of tiles, such as the example shown in <FIG>, the tile skipping ensure that all tiles within a section <NUM> are at most <NUM> "tile hops" away from the vector processing unit <NUM>, thus improving the ASIC chip <NUM> performance by reducing the data path length and resulting data latency by half.

In another example implementation, each tile <NUM> within each row of sections 510a, 510c and within each row of sections 510b, 510d can be configured, through the controllable bus lines, to pass activation inputs along the first dimension <NUM>. For example, some tiles within the sections 510a, 510b, 510c, 510d can be configured to pass activation inputs toward a center of the grid <NUM> or toward the communication interfaces <NUM>. The tiles <NUM> within each row can be further configured skip adjacent tiles, e.g., by hardwiring the controllable bus lines between tiles. For example, a tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a (where the variable i corresponds to the row position and the variable j corresponds to the column position) can be configured to pass activation inputs to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>); similarly, a tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a can be configured to pass activation inputs to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>), and so forth. In some cases, the last tile that is not skipped (e.g., the tile <NUM> located at position (i, j) = (<NUM>, <NUM>)) does not pass the activation input on to another tile.

Similarly, tiles that are skipped may pass activation inputs in the opposite direction. For example, a tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a (where the variable i corresponds to the row position and the variable j corresponds to the column position) can be configured to activation inputs to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>); similarly, a tile <NUM> at a position (i, j) = (<NUM>, <NUM>) in the first section 510a can be configured to pass activation inputs to a tile <NUM> at a position (i, j) = (<NUM>, <NUM>), and so forth. In some cases, the last tile that is not skipped (e.g., the tile <NUM> located at position (i, j) = (<NUM>, <NUM>)) does not pass the activation input on to another tile. By skipping tiles, it is possible, in some implementations, to improve the ASIC chip <NUM> performance by reducing the data path length and resulting data latency by half.

As explained herein, in some implementations, one or more of the tiles <NUM> are dedicated to storing control information. That is, the tiles <NUM> dedicated to storing control information do not take part in performing calculations on input data such as weight inputs and activation inputs. Control information can include, e.g., control data for configuring the controllable bus lines during operation of the ASIC chip <NUM> so that data can be moved around the ASIC chip <NUM>. The control data can be provided to the controllable bus lines in the form of control signals for controlling the conveyer elements and multiplexers of the controllable bus lines. The control data specifies whether particular conveyer elements of the controllable bus lines pass data to a next conveyer element of the controllable bus line so that data is transferred among the tiles according to a predetermined schedule. The control data additionally specifies whether data is transferred from or to a bus line. For example, the control data can include control signals that direct a multiplexer to transfer data from a bus line to memory and/or other circuitry within a tile. In another example, the control data can include control signals that direct a multiplexer to transfer data from the memory and/or circuitry within the tile to the bus line. In another example, the control data can include control signals that direct a multiplexer to transfer data between a bus line and the communications interface <NUM> and/or between the bus line and the vector processing unit <NUM>. Alternatively, as disclosed herein, dedicated control tiles are not used. Rather, in such cases, the local memory of each tile stores the control information for that particular tile.

<FIG> illustrates example of a tile <NUM> for use in the ASIC chip <NUM>. Each tile <NUM> includes local memory <NUM> and a computational array <NUM> coupled to the memory <NUM>. The local memory <NUM> includes physical memory positioned proximate to the computational array <NUM>. The computational array <NUM> includes multiple cells <NUM>. Each cell <NUM> of the computational array <NUM> includes circuitry configured to perform a computation (e.g., a multiply and accumulate operation) based on data inputs, such as activation inputs and weight inputs, to the cell <NUM>. Each cell can perform the computation (e.g., the multiply and accumulation operation) on a cycle of the clock signal. The computational array <NUM> can have more rows than columns, more columns than rows, or an equal number of columns and rows. For instance, in the example shown in <FIG>, the computational array <NUM> includes <NUM> cells arranged in <NUM> rows and <NUM> columns. Other computational array sizes are also possible, such as computational arrays having <NUM> cells, <NUM> cells, <NUM> cells, or <NUM> cells, among others. Each tile can include the same number of cells and/or the same size computational array. The total number of operations that can be performed in parallel for the ASIC chip then depends on the total number of tiles having the same size computational array within the chip. For example, for the ASIC chip <NUM> shown in <FIG>, which contains approximately <NUM> tiles, this means that approximately <NUM>,<NUM> computations can be performed in parallel every cycle. Examples of clock speeds that may be used include, but are not limited to, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. The computational arrays <NUM> of each individual tile is a subset of the larger systolic array of tiles.

The memory <NUM> contained in the tile <NUM> can include, e.g., random-access memory (RAM), such as SRAM. Each memory <NUM> can be configured to store (<NUM>/n)th of the total memory associated with n tiles <NUM> of the ASIC chip illustrated in <FIG>. The memory <NUM> can provided as a single chip or in multiple chips. For example, memory <NUM> shown in <FIG> is provided as four single-port SRAMs, each of which is coupled to the computational array <NUM>. Alternatively, the memory <NUM> can be provided as two single-port SRAMs or eight single-port SRAMS, among other configurations. The joint capacity of the memory can be, but is not limited to, e.g., <NUM> kB, <NUM> kB, 64kB, or <NUM> kB, after error correction coding. By providing the physical memory <NUM> locally to the computational arrays, the density of wiring for the ASIC <NUM> can be, in some implementations, vastly reduced. In an alternate configuration in which memory is centralized within the ASIC <NUM>, as opposed to provided locally as described herein, may require a wire for each bit of memory bandwidth. The total number of wires needed to cover each tile of the ASIC <NUM> would far exceed the available space within the ASIC <NUM>. In contrast, with dedicated memory provided for each tile, the total number of required to span the area of the ASIC <NUM> can be substantially reduced.

The tile <NUM> also includes controllable bus lines. The controllable bus lines may be categorized into multiple different groups. For example, the controllable bus lines can include a first group of general purpose controllable bus lines <NUM> configured to transfer data among tiles in each cardinal direction. That is, the first group of controllable bus lines <NUM> can include: bus lines 610a configured to transfer data toward a first direction along the first dimension <NUM> of the grid of tiles (referred to as "East" in <FIG>); bus lines 610b configured to transfer data toward a second direction along the first dimension <NUM> of the grid of tiles (referred to as "West" in <FIG>), in which the second direction is opposite to that of the first direction; bus lines 610c configured to transfer data toward a third direction along the second dimension <NUM> of the grid of tiles (referred to as "North" in <FIG>); and bus lines 610d configured to transfer data toward a fourth direction along the second dimension <NUM> of the grid of tiles (referred to as "South" in <FIG>), in which the fourth direction is opposite to the third direction. General purpose bus lines <NUM> can be configured to carry control data, activation input data, data from and/or to the communications interface, data from and/or to the vector processing unit, and data to be stored and/or used by the tile <NUM> (e.g., weight inputs). The tile <NUM> may include one or more control elements <NUM> (e.g., flip-flops and multiplexers) for controlling the controllable bus lines, and thus routing data to and/or from the tile <NUM> and/or from memory <NUM>.

The controllable bus lines also can include a second group of controllable bus lines, referred to herein as computational array partial sum bus lines <NUM>. The computational array partial sum bus lines <NUM> can be configured to carry data output from computations performed by the computational array <NUM>. For example, the bus lines <NUM> can be configured to carry partial sum data obtained from the rows in the computational array <NUM>, as shown in <FIG>. In such case, the number of bus lines <NUM> would match the number of rows in the array <NUM>. For instance, for a 8x8 computational array, there would be <NUM> partial sum bus lines <NUM>, each of which is coupled to the output of a corresponding row in the computational array <NUM>. The computational array output bus lines <NUM> can be further configured to couple to another tile within the ASIC chip, e.g., as inputs to a computational array of another tile within the ASIC chip. For example, the array partial sum bus lines <NUM> of tile <NUM> can be configured to receive inputs (e.g., partial sums 620a) of a computational array of a second tile that is located at least one tile away from the tile <NUM>. The outputs of computational array <NUM> then are added to the partial sum lines <NUM> to produce new partial sums 620b, which may be output from the tile <NUM>. The partial sums 620b then may be passed to another tile or, alternatively, to the vector processing unit. For example, each bus line <NUM> may be coupled to a corresponding segment (such as segments <NUM> in <FIG>) of the vector processing unit.

As explained with respect to <FIG>, the controllable bus lines can include circuitry such as conveyer elements (e.g., flip-flops) configured to allow data to be conveyed along the bus lines. In some implementations, each controllable bus line includes, for each tile, a corresponding conveyer element. As further explained with respect to <FIG>, the controllable bus lines can include circuitry such as multiplexers configured to allow data to be transferred among the different tiles, the vector processing unit and the communications interface of the ASIC chip. The multiplexers can be located wherever there is a source or sink for data. For example, in some implementations, as shown in <FIG>, control circuitry <NUM>, such as multiplexers, can be located at crossings of controllable bus line (e.g., at the crossing of general purpose bus lines 610a and 610d, at the crossing of general purpose bus lines 610a and 610c, at the crossing of general purpose bus lines 610b and 610d, and/or at the crossing of general purpose bus lines 610b and 610c). The multiplexers at the bus line crossings can be configured to transfer data between the bus lines at the crossings. Accordingly, by proper operation of the multiplexers, it can be possible to change the direction in which data travels over the controllable bus lines. For example, data traveling along the first dimension <NUM> on general purpose bus lines 610a can be transferred to general purpose bus lines 610d, such that the data instead travels along the second dimension <NUM>. In some implementations, multiplexers can be located adjacent to the memory <NUM> of the tile <NUM> so that data can be transferred to and/or from memory <NUM>.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification M.

A computer program which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and pointing device, e.g., a mouse, trackball, or a presence sensitive display or other surface by which the user can provide input to the computer. Also, a computer can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone, running a messaging application, and receiving responsive messages from the user in return.

Claim 1:
A method performed by a device comprising:
a tile array comprising a plurality of tiles arranged in a plurality of tile rows (<NUM>,<NUM>, <NUM>, <NUM>) and a plurality of tile columns (<NUM>, <NUM>, <NUM>, <NUM>), each tile column comprising a vector accumulator (<NUM>, <NUM>, <NUM>, <NUM>) associated with each column, wherein the plurality of tile columns comprises a plurality of wide columns of the tile array, wherein each wide column of the tile array comprises two or more columns of the tile array; and
a plurality of input RAMs (<NUM>, <NUM>, <NUM>, <NUM>), and a plurality of output RAMs (<NUM>, <NUM>, <NUM>, <NUM>),
the method comprising:
receiving a plurality of input activations for a first layer of a neural network model from the input RAMs;
partitioning the plurality of input activations into a plurality of pixel wide columns, wherein each pixel wide column corresponds to a respective wide columns of the tile array and wherein each pixel wide column comprises a plurality of pixels, each pixel comprising a plurality of features of the plurality of input activations;
distributing features of each pixel of a pixel wide column along the tiles of a single column in the respective wide column of the tile array; and
performing, at each time step of a plurality of time steps, wherein each time step corresponds respectively to operations performed on tile columns within each tile column of the plurality of wide columns of the tile array, operations comprising:
performing respective multiplications of a respective input activation and a respective weight using tiles in respective tile columns for the time step,
computing, using the vector accumulator for the tile column, a respective output result for each respective tile column for the time step, including computing a sum of results of the multiplications for the tile column, and
storing the respective output result for the tile column in a particular output RAM having a location within the same tile column and on a row from which the output result will be read by tiles corresponding to a subsequent layer of the neural network model.