PaperlayerView exact revision on arXiv

Source-linked AI summary

The Cost of Application-Class Processing: Energy and Performance Analysis of a Linux-ready 1.7GHz 64bit RISC-V Core in 22nm FDSOI Technology

Florian Zaruba, Luca Benini

arXiv:1904.05442v1cs.AR

TL;DR

The paper asks how much energy and performance cost is introduced when RISC-V gains the functionality needed for Linux-class application execution. It analyzes an open 64-bit Ariane core using silicon and calibrated simulations, finding substantial costs for application-class features while identifying ISA heterogeneity and targeted extensions as efficiency opportunities.

  • Problem

    Most existing RISC-V cores focus on the base integer subset and lack application-class features such as virtual memory, limiting detailed evidence about their hardware energy impact.

  • Method

    The study analyzes Ariane’s RISC-V microarchitecture and ISA using silicon measurements and silicon-calibrated post-layout simulations of a 22 nm taped-out core.

  • Results

    Up to 1.65 DMIPS/MHz is reported for Ariane, while TLB lookup can account for up to 27% of overall instruction energy and ALU computation below 1%.

  • Takeaways & Limitations

    The analysis supports ISA-heterogeneous systems combining compute-centric bare-metal cores with fewer application-class management cores to improve energy efficiency.

Abstract

from arXiv · show

The open-source RISC-V ISA is gaining traction, both in industry and academia. The ISA is designed to scale from micro-controllers to server-class processors. Furthermore, openness promotes the availability of various open-source and commercial implementations. Our main contribution in this work is a thorough power, performance, and efficiency analysis of the RISC-V ISA targeting baseline "application class" functionality, i.e. supporting the Linux OS and its application environment based on our open-source single-issue in-order implementation of the 64 bit ISA variant (RV64GC) called Ariane. Our analysis is based on a detailed power and efficiency analysis of the RISC-V ISA extracted from silicon measurements and calibrated simulation of an Ariane instance (RV64IMC) taped-out in GlobalFoundries 22 FDX technology. Ariane runs at up to 1.7 GHz and achieves up to 40 Gop/sW peak efficiency. We give insight into the interplay between functionality required for application-class execution (e.g. virtual memory, caches, multiple modes of privileged operation) and energy cost. Our analysis indicates that ISA heterogeneity and simpler cores with a few critical instruction extensions (e.g. packed SIMD) can significantly boost a RISC-V core's compute energy efficiency.

I. INTRODUCTION

The paper examines the energy and performance costs of extending RISC-V from simpler cores to Linux-capable application-class processors. It presents Ariane, an open 64-bit in-order core, and evaluates its trade-offs using silicon measurements and calibrated simulations.

  • Motivation: Linux-capable application-class processors require substantial hardware support, including TLBs and a page-table walker for fast address translation.The paper also notes that Linux systems typically require off-chip main memory, which is inefficient to access constantly.
  • Motivation: Full-featured operating-system support provides standardized user-program interfaces, memory management, isolation, libraries, drivers, and additional security.
  • Motivation: RISC-V modularity enables analysis of energy impacts across microarchitectures ranging from low-cost microcontrollers to Linux-capable server-class CPUs.
  • Results: 1.7 GHz and up to 40 Gop/s W characterize the reported core frequency and peak efficiency.
  • Contributions: Ariane is an open-sourced, single-issue, in-order, 64-bit application-class processor implemented and silicon-integrated in a 22 nm SOI process.
  • Contributions: The study explores performance and efficiency trade-offs through silicon measurements and silicon-calibrated post-layout simulations.

II. ARCHITECTURE

Ariane is a six-stage, single-issue, in-order RV64 core whose pipeline and functional units are organized to support application-class execution while controlling critical-path length. Its design uses handshaked stages and scoreboard-based tracking around execution.

  • Core organization: Ariane is a 64-bit, single-issue, in-order RISC-V core with multiply/divide, atomics, floating point, compressed instructions, privileged instructions, and SV39 virtual memory.Its six-stage pipeline targets logic depth below 30 NAND gate equivalents while limiting IPC losses.
  • Instruction fetch: Instruction fetch combines a virtually indexed, physically tagged instruction cache with simultaneous page-offset indexing and instruction-TLB translation.A TLB miss stalls the cache pipeline until translation becomes valid.
  • Pipeline: The six pipeline stages exchange data through handshaking, while the scoreboard wraps execution and interfaces with issue and commit.
  • Execution and commit: The architecture distinguishes fixed-latency integer, multiply/divide, and CSR units from variable-latency floating-point and load/store units.Instructions may retire out of order from functional units, while commit retires them in program order.

A. Branch Prediction

Ariane mitigates control-flow penalties with multiple next-PC prediction mechanisms and lightweight fetch pre-decoding. Its application-class privilege and memory-ordering features add additional pipeline and synchronization requirements.

  • Branch Prediction: Branch mispredictions flush frontend, decode, and issue stages, introducing at least five cycles of latency and potentially more on TLB or instruction-cache misses.
  • Branch Prediction: Ariane uses a Branch History Table, Branch Target Buffer, Return Address Stack, and fetch pre-decoding to predict and redirect control flow.
  • Branch Prediction: A two-bit saturation-counter BHT predicts branch outcomes, with static backward-taken and forward-not-taken prediction as a fallback.
  • Application-class support: Operating-system support requires separate configurable instruction and data TLBs plus a hardware page-table walker that queries memory after translation misses.
  • Application-class support: Privilege-changing and CSR operations execute non-speculatively in commit and can require complete pipeline flushing because they alter architectural or translation state.
  • Memory ordering: Separate instruction, data, and address-translation streams require dedicated fence-based synchronization, while Ariane can flush flip-flop-based TLBs in one cycle.

E. Register Files

Ariane separates floating-point and integer register files and offers implementation choices that trade area against clocking requirements. Its scoreboard tracks in-flight instructions and resolves write hazards before ordered retirement.

  • Register Files: Floating-point and integer registers use physically separate register files, each configurable as latch-based or flip-flop-based.
  • Register Files: The latch-based register-file implementation is approximately half the area of the flip-flop version.Latch capture occurs on the falling clock edge, making a known duty cycle important for high-speed clock generators.
  • Scoreboard: The scoreboard is a circular buffer between issue and execute that tracks issued instructions, source and destination registers, and data hazards.
  • Scoreboard: Speculative functional-unit results are forwarded through the scoreboard, while commit retires completed instructions and a lightweight renaming scheme resolves WAW hazards.

G. Functional Units

Ariane’s functional units cover arithmetic, memory, floating-point, control-flow, CSR, and multiply/divide operations, while interfaces and debugging support application-class execution.

  • G. Functional Units: Ariane integrates six functional units: ALU, LSU, FPU, branch unit, CSR unit, and multiplier/divider.The LSU supports integer and floating-point loads/stores and atomic memory operations; the FPU includes custom trans-precision extensions.
  • G. Functional Units: The write-back data cache supports hit-under-miss operation, while a variable-size store buffer hides store latency.The store buffer is intended to let common operating-system context-store routines retire at an IPC of 1.
  • G. Functional Units: Both caches add an output pipeline stage because cache memories are slower than logic, enabling path balancing through clock de-skewing.The instruction and data caches are virtually indexed and physically tagged, with configurable associativity and line size.
  • G. Functional Units: Ariane connects through one AXI master port and supports four interrupt sources for machine, supervisor, timer, and software interrupts.The port is arbitrated among instruction fetch, data-cache refills and write-backs, and cache bypasses.
  • G. Functional Units: Its execution-based debug interface reuses instruction execution to keep debug hardware minimally invasive to the microarchitecture.Debug instructions are fetched from a debug RAM after an interrupt-like signal places the core in debug mode.

K. Tracing and Performance Counters

The implementation provides extensive simulation tracing and hardware performance counters while integrating application-class SoC infrastructure and configurable cache and translation resources.

  • K. Tracing and Performance Counters: RTL tracing records register and memory accesses together with physical and virtual addresses and current values.Program-counter tracing is not supported in hardware.
  • K. Tracing and Performance Counters: Performance counters cover cycles, retired instructions, cache and TLB misses, loads and stores, exceptions, and branch-prediction metrics.The counters are mapped into the RISC-V CSR address space.
  • K. Tracing and Performance Counters: The design’s L1 memory interface and virtual-memory support create complexity because the architecture must manage latency while sustaining useful work per cycle.The discussion highlights scheduling and privileged architectural state as additional design challenges.
  • K. Tracing and Performance Counters: Ariane’s coreplex communicates with the SoC through a full-duplex 64-bit AXI interconnect and shares 520 kB of on-chip scratchpad memory.The SoC also includes HyperRAM, SPI, UART, and I2C peripherals.
  • K. Tracing and Performance Counters: The taped-out instance uses 16 kB four-way instruction cache, 32 kB eight-way data cache, and 16-entry instruction and data TLBs.The coreplex can be separately supplied and powered down, and its logic cells support forward body biasing.

A. Physical Design

Physical design and characterization examine timing, power, area, and instruction-class behavior using silicon measurements and calibrated post-layout analysis.

  • A. Physical Design: The most critical paths run through the data caches, where eight-way tag comparison, data selection, wire delay, and limited routing resources increase timing difficulty.Special routing channels and hold-time fixing were applied around the memory macros.
  • A. Physical Design: The evaluation includes ALU, multiplication, division, loads and stores with or without virtual memory, and a mixed matrix-multiplication workload.The mixed workload exercises the architectural features and is also used for speed measurements.
  • A. Physical Design: 210 kGE is the total core area excluding cache memories at a 1.5 ns target timing point.The area breakdown is presented in Figure 5.
  • A. Physical Design: Silicon and post-layout measurements agree within 10%, enabling calibrated power estimates and per-unit energy characterization.Separate supplies for the core, cache array, and periphery support detailed silicon power measurements.

B. Discussion

Ariane reaches up to 1.65 DMIPS/MHz, with measured branch prediction and IPC depending on configuration and load latency.

  • B. Discussion: 1.65 DMIPS/MHz is reported for Ariane, depending on branch-prediction configuration and load latency.With a 128-entry BHT and 64-entry BTB, Dhrystone has a 5.77% mispredict rate and 0.82 IPC.

1) Instruction and data caches:

Ariane’s application-class features impose substantial energy, area, and performance costs, especially through caches, virtual memory, and wider datapaths. The analysis also finds that targeted ISA extensions can improve efficiency more effectively than clock-speed optimization alone.

  • 1) Instruction and data caches:: Private L1 instruction and data caches are the largest units and create the design’s critical path through SRAM delay, tag comparison, data selection, and routing.
  • 1) Instruction and data caches:: 220 MHz to 1.7 GHz is achieved across 0.5 V to 1.15 V, while cache SRAMs stop functioning below 0.5 V.
  • 1) Instruction and data caches:: 30% higher speed is available from forward body-biasing at 0.5 V, but the speedup falls to 6% at 1 V while leakage increases exponentially.
  • 2) Application-class features:: Up to 27% of overall instruction energy can come from TLB lookup, whereas actual ALU-centric computation uses below 1%.
  • 2) Application-class features:: User and supervisor modes plus architectural state add significant CSR-file area and power, while TLB indexing remains costly even when translation is disabled.
  • 3) Multiplication and divisions:: The multiplier occupies over 13% of core area and consumes up to 4.4 pJ per active cycle, while serial division has minimal overall impact.
  • C. Comparison with non-application-class cores: 51.8 pJ for Ariane versus 10 pJ for a technology-scaled 32-bit embedded core illustrates the application-class energy overhead, driven mainly by private L1 caches.
  • C. Comparison with non-application-class cores: Up to 3.8 pJ per instruction, or 38% of the 32-bit core, is consumed by TLBs and the PTW; three-cycle data-cache latency and branch mispredictions also reduce IPC.

V. RELATED WORK

Prior RISC-V work includes configurable in-order and out-of-order cores, but detailed silicon-calibrated functional-unit energy analyses remain scarce. This study contributes an open, reproducible application-class implementation and energy breakdown for Ariane.

  • Most existing RISC-V implementations focus on the base integer subset and omit application-class features such as virtual memory.
  • The study presents what it identifies as the first energy breakdown across functional units linked to ISA requirements on a competitive 64-bit application-class core.
  • Rocketchip provides a parameterized 32- or 64-bit in-order Rocket core and can substitute the four-issue, out-of-order Boom core, but Boom has no published power results.
  • SHAKTI’s comparable 64-bit in-order C-class core reports 1.68 DMIPS/MHz, while Ariane runs at approximately twice its speed and consumes less power at higher speeds.
  • Existing processor energy studies often lack silicon-calibrated analysis or detailed energy-cost breakdowns because commercial microarchitectures are closed.
  • Ariane’s open ISA, microarchitecture, and RTL make its results independently reproducible and support later modification and improvement.

VI. CONCLUSION

Ariane is an open-source 64-bit, single-issue, in-order RISC-V core taped out in 22 nm FDSOI, supporting rigorous efficiency analysis. The analysis connects RISC-V openness and architectural flexibility with potential energy-efficiency gains from heterogeneous systems.

  • Ariane is a 64-bit, single-issue, in-order core taped out in 22 nm FDSOI technology.
  • The work provides a rigorous efficiency analysis of the RISC-V ISA and its hardware impact based on Ariane’s microarchitecture.
  • Ariane was open-sourced with RTL simulation support, an FPGA bitstream, and a pre-built Linux image for industry and research use.
  • Most computation can run on simpler non-application-class cores, while application-class features remain necessary for full-featured operating systems.
  • RISC-V openness and available encoding space support exploration of architectures and ISA extensions aimed at improving future computing-system efficiency.
Loading 1904.05442v1…