NEC SX-Aurora TSUBASA

Version 2 Vector Engine[8]

Version 1 Vector Engine

The version 1.0 of the Vector Engine was produced in 16 nm FinFET process (from TSMC) and released in three SKUs (subsequent versions add an E at the end):[9]

Each of the eight SX-Aurora cores has 64 logical vector registers.[10] These have 256 x 64 Bits length implemented as a mix of pipeline and 32-fold parallel SIMD units. The registers are connected to three FMA floating-point multiply and add units that can run in parallel, as well as two ALU arithmetical logical units handling fixed point operations and a divide and square root pipe.[10] Considering only the FMA units and their 32-fold SIMD parallelism, a vector core is capable of 192 double precision operations per cycle.[10] In "packed" vector operations, where two single precision values are loaded into the space of one double precision slot in the vector registers, the vector unit delivers twice as many operations per clock cycle compared to double precision.

A Scalar Processing Unit (SPU) handles non-vector instructions on each of the cores.

The memory of the SX-Aurora TSUBASA processor consists of six HBM2 second generation high-bandwidth memory modules implemented in the same package as the CPU with the help of Chip-on-Wafer-on-Substrate technology. Depending on the processor model, the HBM2 modules are either 4 or 8 die 3D modules with either 4 or 8 GB capacity, each. The SX-Aurora CPUs thus have either 24GB or 48GB HBM2 memory. The models implemented with large HBM2 modules have 1.2TB/s memory bandwidth.[11]

The cores of a vector engine share 16MB of "Last-Level-Cache" (LLC), a write-back cache directly connected to the vector registers and the L2 cache of the SPU. The LLC cache line size is 128 Bytes. The priority of data retention in the LLC can to some extent be controlled in software, allowing the programmer to specify which of the variables or arrays should be retained in cache, a feature comparable to that of the Advanced Data Buffer (ADB) of the NEC SX-ACE.

NEC is currently selling the SX-Aurora TSUBASA vector engine integrated into four platforms:[12][9]

• A111-1: a tower PC with one VE card of type 10B
• A101-1: a tower PC with one VE card of type 10CE
• A311-4: a dual socket 1U 19 inch rack-mountable Xeon scalable server equipped with up to four VE cards of type BE
• A311-8: a dual socket 4U 19 inch rack-mountable Xeon scalable server with up to eight VE cards of type BE
• A511-64: a 19 inch rack equipped with 64 VEs of type AE. This is the only configuration that is explicitly sold as a supercomputer.

Within a VH node VEs can communicate with each other through PCIe. Large parallel systems built with SX-Aurora use Infiniband in a PeerDirect setup as interconnect.

NEC also used to sell the SX-Aurora TSUBASA vector engine integrated into five platforms:

• A100-1: a tower PC with one VE card of type 10C.
• A300-2: a single socket 1U rack-mountable Skylake server equipped with up to two VE cards of type 10B or 10C.
• A300-4: a dual socket 1U rack-mountable Skylake server equipped with up to four VE cards of type 10B or 10C.
• A300-8: a dual socket 4U rack-mountable Skylake server with up to eight VE cards of type 10B or 10C.
• A500-64: a rack equipped with either Intel Xeon Silver 4100 family or Intel Xeon Gold 6100 family CPUs and 32, 48 or 64 VEs of type 10A or 10B.[13]

All types are exclusively air cooled with the exception of the A500 series, which also utilizes watercooling.

The operating system of the vector engine (VE) is called "VEOS", and has been offloaded entirely to the host system, the vector host (VH).[14] VEOS consists of kernel modules and user space daemons that:

• manage VE processes and their scheduling on the VE
• manage the virtual memory address spaces of the VE processes
• handle transfers between VH and VE memory with the help of the VE DMA engines
• handle interrupts and exceptions of VE processes, as well as their system calls.[15]

VEOS supports multitasking on the VE and almost all Linux system calls are supported in the VE libc.[15] Offloading operating system services to the VH shifts OS jitter away from the VE at the expense of increased latencies.[15] All VE operating system related packages are licensed under the GNU General Public License and have been published at github.com/veos-sxarr-nec.

A Software Development Kit is available from NEC for developers and customers. It contains proprietary products and must be purchased from NEC. The SDK contains:

• C, C++ and Fortran compilers that support automatic vectorization and automatic parallelization as well as OpenMP.[16]
• Performance optimization tools: ftraceviewer and veperf.[17]
• Optimized numerical libraries for the VE: BLAS, SBLAS, LAPACK, SCALAPACK, ASL, Heterosolver.[18]

NEC MPI is also a proprietary implementation and is conforming to the MPI-3.1 standard specification.[19]

Hybrid programs can be created that use the VE as an accelerator for certain host kernel functions by using VE offloading C-API.[20] To some extent VE offloading is comparable to OpenCL and CUDA, but provides a simpler API and allows the kernels to be developed in normal C, C++ or Fortran and use almost any syscall on the VE. Python bindings to VEO are available at github.com/SX-Aurora/py-veo.