Basic Architecture

As shown in the following figure, operators developed using Ascend C run on the AI Core. The Ascend C programming model is introduced based on the abstraction of the AI Core hardware architecture. Understanding the hardware architecture helps you better understand the programming model. For experienced developers who need to complete high-performance programming, it is even more important to learn about the hardware architecture. Many contents in the operator practice reference are introduced based on this chapter.

The AI Core is responsible for executing cube and vector computation–intensive tasks. It consists of the following components:

Take Atlas A2 training product / Atlas A2 inference product as an example. The following figure shows its hardware architecture.

This section first introduces the key concepts and terms related to the hardware architecture and the working mode of the AI Core, laying a foundation for understanding the subsequent content. Then, using Atlas A2 training product / Atlas A2 inference product as an example, this section provides an introduction to the basic architecture of the AI Core. It first describes the basic functions and structures of the compute units, storage units, and movement units, and then uses typical data flow and control flow examples to help you gain a deeper understanding of the working principles of the hardware architecture. For details about the specific architecture specifications of different product models, see Architecture Specifications.

Key Concepts and Terms

AI Core Working Modes

In Ascend C programming, the working modes of different products are as follows:
  • Atlas inference product : coupled mode
  • Atlas training product : coupled mode
  • Atlas A2 training product / Atlas A2 inference product : separated mode
  • Atlas A3 training product / Atlas A3 inference product : separated mode
  • Atlas 350 Accelerator Card: separated mode
  • Atlas 200I/500 A2 inference product : coupled mode

Note: For the Atlas 200I/500 A2 inference product , the hardware working mode can be either coupled mode or separated mode. In coupled mode, you only need to concern about the number of AI Cores, and do not need to concern about the number of Vector Cores and Cube Cores. In separated mode, you need to concern about the number of AI Cores, Vector Cores, and Cube Cores. In Ascend C programming scenarios, only the coupled mode is supported.

Compute Units

The compute units are the core of powerful compute capabilities of the AI Core, including the Cube Unit, Vector Unit, and Scalar Unit. These three units process different types of data in the AI Core.

Storage Units and DMA Units

To fully leverage the powerful computing capability of the AI processors, the prerequisite is that the input data can be fed to the compute units in a timely and accurate manner. Therefore, the memory system needs to be elaborately designed to ensure the data supply required by the compute units.

As shown in the following figure, an AI Core includes multiple levels of local memory (internal storage), and loads data from the global memory (external storage) to the local memory for computation. The local memory of an AI Core includes the L1 Buffer, L0 Buffer, Unified Buffer, and so on. An AI Core also contains memory transfer engines (MTEs) to facilitate data movement and copy, which can convert the data format or type during data movement.

For details about the internal storage units and DMA units, see Table 1 and Table 2.

Figure 6 Storage units
Table 1 Description of storage units

Storage Unit

Description

L1 Buffer

As a general part of the local memory, the L1 Buffer offers a large data buffer in the AI Core. It can temporarily store data that needs to be repeatedly used in the Cube Unit, thereby reducing the frequency that data is read from or written to the bus.

L0A Buffer/L0B Buffer

They store the inputs of Cube instructions.

L0C Buffer

It stores the outputs of Cube instructions, which are part of the inputs for accumulation.

Unified Buffer

The Unified Buffer stores the inputs and outputs of vector and scalar computations.

BT Buffer

The BiasTable (BT) Buffer stores the bias in cube computations.

FP Buffer

The FixPipe (FP) Buffer stores quantization parameters and ReLU parameters.

Table 2 DMA units

DMA Unit

Description

MTE1

Moves data in the following paths:

  • L1->L0A/L0B
  • L1->BT Buffer

MTE2

Moves data in the following paths:

  • GM->{L1, L0A/B}. In this path, data is moved based on the fractal size. If the data movement meets the cache line size alignment requirements, the performance is better.
  • GM->UB. Data movement based on the cache line size will achieve better performance.

MTE3

Moves data in the following paths:

  • UB -> GM

FixPipe

Moves data in the following paths. (The data format or type can be converted during data movement.)

  • L0C->{GM/L1}
  • L1->FP Buffer
  • The size of a storage unit varies with the AI processor type. You can call GetCoreMemSize to get the size.
  • By default, all data that is read from or written to the GM through the DMA units is cached in the L2 cache to accelerate the access speed and improve the access efficiency. The L2 cache outside the core loads data in the unit of cache lines. The cache line size (128, 256, or 512 bytes) varies with hardware specifications.

Typical Data Flows

Typical Instruction Flows

Multiple instructions enter the iCache from the system memory through the bus. Based on the instruction type, there are two kinds of subsequent instruction execution processes:

Figure 7 Instruction processing by category
Instructions in the same queue are executed according to their enqueue sequence, and instructions in different queues can be executed in parallel. Such parallelism improves overall execution efficiency. For data dependency that may occur during parallel execution, the Event Sync module inserts synchronization instructions to control pipeline synchronization. The PipeBarrier and SetFlag/WaitFlag APIs are provided to ensure that the instructions in a queue and across queues are executed based on the logical relationship.
  • PipeBarrier is an instruction used to control the execution sequence in a queue. (Although instructions are executed in sequence, it does not mean that the execution of the previous instruction ends when the next instruction starts to be executed.) PipeBarrier ensures that all data read and write operations of the previous instruction are completed before the next instruction is executed.
  • SetFlag and WaitFlag are a pair of inter-queue synchronization instructions.
    • SetFlag: The current instruction starts to be executed after all read and write operations of the current instruction are completed and the corresponding flag bit in hardware is set to 1.
    • WaitFlag: When this instruction is executed, if the corresponding flag bit is 0, the subsequent instructions in the queue are blocked; if the corresponding flag bit is 1, the subsequent instructions are executed after this bit is changed to 0.

Ascend C provides synchronization control APIs. You can use this type of APIs to implement synchronization control. Generally, there is no need to consider synchronization when programming based on the programming model and paradigm described in Programming Model. The programming model implements synchronization control. Using the programming model and paradigm is recommended. Manual synchronization control may complicate programming.

However, we still hope that you can understand the basic principles of synchronization to better understand and design parallel compute programs. In a few cases, you need to manually insert synchronization. For details, see Requirements on Enabling Manual Synchronization Control.