X-HEEP

X-HEEP (eXtendable Heterogeneous Energy-Efficient Platform) is a RISC-V microcontroller described in SystemVerilog that can be configured to target small and tiny platforms as well as extended to support accelerators. The cool thing about X-HEEP is that we provide a simple customizable MCU, so CPUs, common peripherals, memories, etc. so that you can extend it with your own accelerator without modifying the MCU, but just instantiating it in your design. By doing so, you inherit an IP capable of booting RTOS (such as FreeRTOS) with the whole FW stack, including HAL drivers and SDK, and you can focus on building your special HW or APP supported by the microcontroller.

X-HEEP supports simulation with Verilator, Questasim, etc. Moreover, FW can be built and linked by using CMake either with GCC or with Clang and/or SEGGER Embedded Studio using gcc. It can be implemented on FPGA, and it supports implementation in Silicon, which is its main (but not only) target. You are welcome to explore our X-HEEP repository or our X-HEEP paper for a deeper description of the platform.

Architecture

The architecture is thought to be divided into the following power domains: CPU subsystem domain, memory banks domains, peripheral subsystem domain and always-on peripheral subsystem domain. The following image highlights each power domain with a different colour. IPs are carefully selected and grouped in the mentioned power domains in order to maximize energy savings during the processing and acquisition phases of our target ultra-low-power edge-computing applications. We reused several IPs from the most important open-source projects, such as PULP, OpenHW and lowRISC. Moreover, we custom-designed some specific IPs to meet our architectural needs.

You can access an editable version of this diagram for your use in presentations or publications here.

CPU subsystem domain

The CPU subsystem is based on the RISC-V OpenHW Group CPUs as: CVE2, CV32E40P and its variant with the CORE-V-X Interface called CV32E40PX, and finally the CV32E40X CPU, also with the X-IF. All the CPUs are embedded class 32-bit open-source low-power cores. The first three originally designed by ETH Zurich. You can selected your core among those ones. We selected these cores as the first two are mature, verified, implemented in silicon several times, while the latter as extendible with the X-IF. They all features a Harvard architecture with two separate bus interfaces for instructions and data implementing the open bus interface (OBI) protocol. No caches are present in the system. The domain can be easily clock-gated, but it is also thought to be completely switched off when not used for long periods of time.

Memory banks domains

The memory subsystem is divided into multiple banks that can have different sizes of memory used to both program instructions and data. Banks are connected to the bus with dedicated interfaces and this allows you to access multiple banks at the same time without conflicts. Each bank can be individually clock-gated or set in retention to save dynamic and leakage power, respectively. Moreover, the memory subsystem is thought to be fine-grained power-gated, switching off each bank that is not needed.

Peripheral subsystem domain

The peripheral subsystem includes the general-purpose peripherals that are not commonly used during the processing or acquisition phases but that are a nice-to-have in a multi-functional microcontroller. It includes a general-purpose timer, a platform-level interrupt controller (PLIC), an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI) and 24 general-purpose input-output (GPIO). This subsystem is connected to the bus through a single interface but features an internal second level of decoding to direct the request to the proper peripheral. The subsystem can be clock-gated to save dynamic power or it can be switched off when not used for a long time.

Always-on peripheral subsystem domain

The always-on peripheral subsystem includes all IPs we want to keep on for the entire time. We custom-designed the SoC controller, the boot ROM, the power manager, the fast interrupt controller and the DMA in order to meet our needs and requirements. The remaining peripheral IPs, i.e., a general-purpose timer, a universal asynchronous receiver transmitter (UART), 2 SPIs and 8 GPIOs, come from important open-source projects. No power-gating strategy is applied to this domain.

Index

• Getting started
  • 1. Setup
  • 2. Generating the microcontroller
  • 3. Compiling and running software
  • 4. Understanding the Tools
• How to…
  • Compile applications
  • Simulate
  • Integrate Analog / Mixed-Signal simulations
  • Area Plot
  • Debug
  • Execute Code from FLASH
  • Set up an IDE
  • Implement on ASIC
  • Integrate a Peripheral IP
  • Profiling
  • Program the FLASH on the EPFL Programmer
  • SystemC model
  • Update the documentation
• Configuration
  • System Configuration
  • CPU Configuration
  • CORE-V eXtension Interface (CV-X-IF) Configuration
  • Memory Banks Configuration
  • Bus Type Configuration
  • Linker Configuration
  • Pad Configuration
  • Peripheral Configuration
  • Extension Configuration
  • xheep_gen
• eXtending X-HEEP
  • 1. eXtending hardware
  • 2. eXtending software
  • 3. X-HEEP-based eXamples
• Testing
  • Automatic testing
  • VerifHeep
• Peripherals
  • DMA
  • I2C SDK
  • SPI Host
  • SPI slave
  • Serial Link Peripheral Documentation
  • Timer SDK
  • W25Q128JW CONTROLLER
• External Peripherals
  • Digital Level-Crossing (dLC)
• FPGA
  • Run on FPGA
  • FPGA AUP-ZU3: Getting Started & Flash Programming Guide
  • Using ILA for Debugging in Vivado
  • FPGA Genesys2: Use Guide
  • FPGA ZCU104: Getting Started & Flash Programming Guide
• ASICs
  • ASIC Implementations