Architecture Changes from 220x to 351x
Figure 1 shows the 351x architecture. Compared with 220x, the 351x architecture has the following new features:
- Added multiple data channels.
- Increased the number of AI Cores.
- Increased the UB capacity.
- Added the SSBuffer intra-core storage unit, which can be accessed by the AIC and AIV cores through the scalar unit.
- Supported SIMT programming and SIMD and SIMT programming in addition to SIMD programming.
- Adopted the RegBase architecture for AIV cores. Compared with the MemBase architecture of 220x, the RegBase architecture allows direct operations on the vector registers of the chip, achieving greater flexibility and better performance.
The following tables describe the major changes in the 351x architecture. In addition, the 351x architecture supports more data types. For details, see Applicability.
- DMA unit
- Compute unit
Table 2 Compute unit changes Change in 351x
Impact
Affected API
The cube unit does not support the s4 type.
For matrix multiplication of the int4b_t data type, you need to cast the int4b_t data to the int8_t data before performing cube computation.
Mmad
The cube unit does not support the fractal change from ZZ to ZN in the L0A buffer.
In the L0A buffer tiling scenario, the L0A buffer address of the left matrix needs to be recomputed for matrix multiplication.
LoadData/LoadDataWithTranspose
The vector core MemBase architecture is switched to the RegBase architecture.
The performance of basic APIs deteriorates in some scenarios.
Basic APIs in high-dimensional sharding mode
The hardware does not support the subnormal function. Currently, the subnormal function is implemented through software simulation.
You need to set the config template parameters to configure the subnormal computation mode. For details, see Vector Computation.
Ln/Sqrt/Rsqrt/Div/Reciprocal/Exp
4:2 sparse matrix computation is not supported.
You need to use the Vector Core capability to convert a dense matrix into a sparse matrix.
LoadDataWithSparse/MmadWithSparse
- Storage unit
Table 3 Storage unit changes Change in 351x
Impact
Affected API
Deleted the boundary value setting of the L1 buffer.
In the 351x architecture hardware, the registers related to the boundary value setting of the L1 buffer are deleted and the SetLoadDataBoundary API is no longer supported. For details, see Compatibility Solution.
SetLoadDataBoundary
Changed the unified buffer structure. For details about the comparison between the unified buffer structures of the 220x and 351x architectures, see the bank structure comparison.
In the 220x architecture, the unified buffer is divided into 16 bank groups. Each bank group contains three banks, and size of each bank is 4 KB. In the 351x architecture, the unified buffer is divided into 8 bank groups. Each bank group contains two banks, and size of each bank is 16 KB. If a unified buffer conflict occurs, you can refer to Preventing Bank Conflicts of the Unified Buffer to resolve the conflict.
/
- Synchronization
- Others
Table 5 Other changes Change in 351x
Impact
Affected API
Deleted the AIPP hardware-level instructions and implemented the AIPP function through software simulation.
The performance of the AIPP API may deteriorate.
SetAippFunctions/LoadImageToLocal
Deleted the unified buffer exception debugging API because related registers in the 351x architecture are deleted.
The debugging API has no impact on functions.
CheckLocalMemoryIA
