Accelerator

Accelerator Stream

The Accelerator stream will develop and demonstrate fully European processor IPs based on the RISC-V Instruction Set Architecture, providing power efficient and high throughput accelerator tiles within the GPP chip. Using RISC-V allows leveraging open source resources at hardware architecture level and software level, as well as ensuring independence from non-European patented computing technologies.

The EPAC basic building block is a tile containing up to 8 vector processors and specialized units. The processors are coherent, sharing L2 cache banks through a Network-on-Chip, each bank with its associated Home Node agent. through a Network-on-Chip. The processors will support RISC-V vector instructions, and will also control the specialised units dedicated to Stencil and Deep Learning acceleration. The vector and stencil capabilities will address HPC workloads, while the Deep-Learning units will target AI applications.

The vector processor architecture will be based on these guiding principles:

Holistic throughput-oriented vision based on long vectors and task-based models
Hierarchical concurrency and locality exploitation
Communication between programming levels
Make it all look very close to classical sequential programming to ensure productivity

The dedicated unit architecture, on the other hand, will be geared towards a few specific applications. This specificity will be leveraged to explicitly manage the data placement and transfer from and into local scratchpad memories, targeting high-energy efficiency

The EPAC tile will be integrated both as a node in the GPP mesh, and as a stand-alone Test Chip for demonstration and software debugging purposes.

Compiler Explorer – Overview

The compiler team at the Barcelona Supercomputing Center working on EPI have setup of a Compiler Explorer for an LLVM-based compiler that targets the RISC-V and the V-extension (still draft) architecture.

Compiler Explorer is an open-source web application for interactive compiler code generation observation.

We want to use this tool to ease the analysis and study of the compiler code generation when targeting the RISC-V V-extension. This gives us valuable information in co-design as it can quickly expose pain points in the code generation. These pain points may suggest changes in the V-extension architecture or require new code generation strategies or optimizations in the compiler.

Compiler Explorer is intended for small programs or snippets not for large applications.

We have also integrated our own user-space functional emulator `vehave`. This emulator traps the vector extension instructions emitted by the compiler and emulates them with scalar instructions. This way we can execute vector applications and check their correctness under a RISC-V Linux environment. Both real hardware, such as the HiFive Unleashed, or `qemu-user` can be used. Our Compiler Explorer uses `qemu-user`.

Compiler Explorer website is https://repo.hca.bsc.es/epic/

Compiler user guide is available here: user-guide-compiler-explorer

VaRiable Precision Processor VRP

The VaRiable Precision Unit enables efficient computation in scientific domains with extensive use of iterative linear algebra kernels, such as physics and chemistry. Augmenting accuracy inside the kernel reduces rounding errors and therefore improves computation’s stability. Usual solutions for this problem have a very high impact in memory and computation time (e.g. use double precision in the intermediate calculations).

The hardware support of variable precision, byte-aligned data format for intermediate data optimizes both memory usage and computing efficiency. When the standard precision unit cannot reach the expected accuracy with standard precision (aka double), the variable precision unit takes the relay and continues with gradually augmenting precision until the tolerance error constraint is met. The offloading from the host processor (GPP) to the VRP unit is ensured with zero-copy hadnover thanks to IO-coherency between EPAC and GPP.

The VRP is embedded as a functional unit in a 64-bits RISC-V processor pipeline. The unit extends the standard RISC-V Instruction with hardwired arithmetic basic operations in variable precision for scalars: add, subtract, multiply and type conversions. It implements other additional specific instructions for comparisons, type conversion and transfers to cache. The unit features a dedicated register file for storing up to 32 scalars with up to 256 bits of mantissa precision. Its architecture is pipelined for performance, and it has an internal parallelism of 64-bits. Thus, internal operations with higher precisions multiple of 64 bits are executed by iterating on the existing hardware.

The VRP programming model is meant for smooth integration with legacy scientific libraries such as BLAS, MAGMA and linear solver libraries. The integration in the host memory hierarchy is transparent for avoiding the need of data copy, and the accelerator offers a standard support of C programs. The libraries are organized in order to expose the variable precision kernels as compatible replacements of their usual counterparts in the BLAS and solver libraries. The complexity of arithmetic operations is confined as much as possible within the lower level library routines (BLAS). Consistently, the explicit control of precision is exclusively handled at solver level.

Stencil/tensor accelerator STX

From the beginning, EPI explicitly considered “specialised blocks for stencil and deep learning (DL) acceleration. The vector and stencil capabilities will address workloads in HPC centres, while the DL block will target learning acceleration” as part of the acceleration stream motivated by “optimised performance and energy efficiency” for “specialised computations”. In the initial DoA, two different domain-specific accelerators (NTX for machine learning, and a stencil accelerator) were suggested. During the first few months of the project, researchers from Fraunhofer Institute, ETH Zürich and University of Bologna were able to merge the functionality of both units into a very efficient computation engine that has been named STX (stencil/tensor accelerator).

Such “domain-specific accelerators” are now a major trend in industry, as can be seen by multiple new announcements in the 2019 Hot-Chips symposium and AI Summit by industry heavyweights as a multitude of startups that have presented acceleration engines that were based on specialised datapaths and not general purpose vector units, confirming the significant differentiation in architecture needed for achieving top efficiency and performance in the machine learning domain.

The main goal of STX is to achieve a significantly higher (at least 5x-10x) energy efficiency over general purpose/vector units. The efficiency tells us how many computations can be performed with the unit, and the early target for the STX unit was to achieve at least 5x more energy efficiency (TFLOPS/W) than the vector unit on deep learning applications. In the first few months of the project, it became clear that these estimations are rather conservative, and the effective efficiency within EPI chips will be significantly higher. For applications that require only inference using quantized networks, this efficiency will be another 10x higher.

STX has been designed as a modular building block with several parametrization options. Each STX accelerator consists of several clusters of computing units, a typical instance would have four such clusters. Each cluster in turn consists of specialised computing engines as well as up to two RISC-V cores that are used to control the computing engines and perform additional operations. All these units will access a local scratchpad memory, which will be filled using a centralized DMA unit. This configuration allows for 64 GFLOPS (single precision FP), and multiple instances of STX can be instantiated in an EPAC tile.

STX is programmed using OpenMP, there are solutions that allow regular operations to be offloaded to the STX unit from an Arm system (in the GPP) or the 64-bit RISC-V core (in the EPAC tile) using both GCC and LLVM based flows that will be fruther refined as part of the project.

@--author--

--content--

--date--

--title--

--excerpt--