Avoiding Bank Conflicts (Atlas 350 Accelerator Card)

To improve data access efficiency and throughput, the Unified Buffer adopts a bank structure (memory modules of the same size). The Unified Buffer has a total size of 256 KB and is divided into 16 banks. Each bank consists of 512 rows, with each row being 32 bytes long. These 16 banks are further organized into eight bank groups, with each bank group containing two banks. For example, bank7 and bank15 form a bank group.

Figure 1 Bank structure (the arrow direction indicates the memory layout sequence)

Each bank can independently read and write data, and multiple data requests can be processed at the same time. However, when a plurality of read/write operations attempt to access a same bank at the same time, due to a limitation of hardware resources, these operations need to wait in a queue, resulting in a bank conflict and performance deterioration.

Specifically, the Vector Unit can read or write a row of data from or into each bank group in each cycle (an instruction cycle). When multiple read/write operations attempt to access the same bank at the same time, the Vector Unit cannot process all requests in the same cycle. As a result, these requests wait in a queue. This queuing increases the data access latency and reduces the overall system performance.

Typical Scenarios of Bank Conflicts

Bank conflicts can be classified into the following three scenarios:

The following provides some specific examples. Assume that 0x10000 is on bank0 and 0x10020 is on bank1, as shown in the following figure.

Figure 2 Address allocation

How to Avoid Bank Conflicts

There are two methods to avoid bank conflicts: optimizing the computation logic and optimizing address allocation.