Personal tools

Heroino: Design of the next CORE-V Microcontroller

From iis-projects

Jump to: navigation, search

Introduction

The CORE-V MCU serves as a minimal basis to demonstrate the capabilities of the OpenHW Group CORE-V CV32E4 and CVA6 microprocessors, previously known as RI5CY and Ariane and originally developed at ETH Zurich. The SoC consists of a minimal set of peripherals (CLINT, PLIC) as well as I/O (UART). This MCU, called Heroino, is the successor of the famous PULPino, developed to demonstrate the capability of the RI5CY core. Differently from the more complex PULPissimo MCU, whose goal is to be a performant, state-of-the-art MCU, PULPino and Heroino have the goals of make the user experience easy and standard, with industrial standard peripherals subsystem and software (as freeRTOS).

Feature Set

  • Embedded Domain - OBI based
    • Configurable CV32E40P instance.
      • Default parameters chosen to be compatible with the RTL freeze version.
    • TCDM (tightly coupled data memory)
      • Shared, banked, memory for high-performance memory access by both the instruction and the data ports of CV32.
  • Application Domain - AXI based
    • Configurable CVA6 instance
  • Peripheral Domain - APB based
    • PLIC and CLINT interrupt controllers
    • A few key peripherals:
      • UART from lowRISC
      • PLIC from lowRISC
      • [Quad-SPI (to be developed)] optional
      • RISC-V Debug from ETH
      • CLINT from ETH
      • Custom generated bootrom
  • DMA
    • Efficient memory transfers. It can be based on the one from PULP
  • Accelerator
    • A configurable number of ports into the TCDM

Continuous Integration Checks and Artifact generation

  • Verilator compile and run.
  • Check dependencies up-to-date.
  • Check commit messages and commit formats.
  • Verible lint.
  • Any commercial tool lints which we are going to use.
  • Bit-stream generation, at least for the web-pack FPGAs.
    • Store bit-streams as downloadable artifacts on the repository.

Repo organization

  • Flat dependencies, use the vendor.py tool
  • Auto-generated and self-hosted documentation.
  • Linear GIT history. PRs are squashed and committed as one change.


File hierarchy (no submodules, no sub-trees, etc.):

  • doc: Documentation
  • hw: RTL source directory
    • vendor: Vendored external sources
      • axi: AXI dependency
      • apb: APB dependency
      • ...
    • system:
      • src: Top-level and auxiliary files for the core-v-mcu system.
      • sw: Generated linker scripts and file headers.
  • sw: Software repository
    • vendor:
      • compliance_tests
      • riscv-tests
  • README.md: Link to other documentation, small getting-started guide.
  • LICENSE
  • python-requirements.txt: List of Python requirements to be installed.

Architecture

Heroino.png


The Embedded Domain is shown to the left. The OBI crossbar has the memory banks and one port to the AXI crossbar as slaves, and it has the CV32E4, the AXI crossbar and the DMA as master. The banked memory provides the necessary throughput to efficiently serve the instruction and data port of the core as well as the bandwidth requirements of the DMA and the Application domain. The Application domain is based on AXI and it contains the CVA6 core and the DMA as masters. The peripheral subsystem is based on APB and contains the basic peripherals as well as the boot ROM. The JTAG is attached to the RISC-V Debug module, which is a master of the application domain subsystem.

The register interface comes with support for automatically generating register maps based on LowRISC OpenTitan’s reggen tool and can be adapted to APB. This implies that we can very easily support the same set of verified peripherals as in LowRISC OpenTitan.

Wishlist

Future: SPI, SDIO, Camera IF needs DMA, I2C, PWM, GPIO New DMA linked-list of descriptors, ARM DMA 2031 Configurability

IP Sources

Clock and Reset Domains

The CORE-V MCU will consist of a single clock domain. The reset will be partitioned into a non-debug module reset domain which consists of everything except the debug module as well as a power-on reset domain which consists of all reset domains.

Preferably the ndmreset domain would be synchronous. This should be subject to further discussions.

Memory Map

  • 0x8000_0000 - 0xffff_ffff: Main memory, DRAM, simulation memory.
  • 0x4000_0000 - 0x4fff_ffff: TCDM
  • 0x0 - 0x3fff_ffff: Peripherals, SoC, etc.
    • 0x300_0000 - 0x3ff_ffff: PLIC
    • 0x260_0000 - 0x2ff_ffff: Reserved memory
    • 0x250_0000 - 0x25f_ffff: DMA
    • 0x240_0000 - 0x24f_ffff: CLINT
    • 0x230_0000 - 0x23f_ffff: Accelerator
    • 0x220_0000 - 0x22f_ffff: GPIO
    • 0x210_0000 - 0x21f_ffff: I2C
    • 0x200_0000 - 0x20f_ffff: UART
    • 0x1_0000 - 0x1_ffff: Boot ROM
    • 0x0 - 0x1000: Debug module

RTL Tasks:

  • Initial RTL bring-up and connecting the components.
  • Add documentation.
    • User-guide
      • Getting Started
      • Tool setup (maybe provide a Dockerfile)
    • Reference manual, i.e., a more technical description
    • Block-diagrams.
  • Use fusesoc to generate RTL lists, generate top-level and FPGA synthesis. Flattened dependencies can have out-of-tree source file listings and only contain the bare minimum file sets.
  • Verilator bring-up
    • C++ testbench
    • `fesvr` integration for semi-hosted environment
    • `riscv-tests` or standard compliance tests passing.
  • Xcelium bring-up
    • Testbench for commercial synthesizer
    • Potential IP fixes for Xcelium
  • FPGA bring-up, debug connection, preloading of memories (DRAM).
  • Add CI targets:
    • Bitstream generation
    • Lint style checks
    • C code formatting checks.
    • … to be driven by a separate project
  • Coordinate with the OpenHW Group SW Task group for a minimal BSP.

Documentation

Documentation will be automatically generated from markdown files within the repository. I would suggest using mkdocs with the Material them. Static HTML files can be hosted directly on Github.

Verification

Verification efforts shall focus on the SoC components. IPs themselves are tested stand-alone.

ASIC Implementation

The chip will be taped-out as part of the project in TSCM65 technology.

Required Skills

To work on this project, you will need:

  • to have worked in the past with at least one RTL language (SystemVerilog or Verilog or VHDL) - having followed the VLSI1 / VLSI2 courses is recommended
  • to have prior knowedge of hardware design

Other skills that you might find useful include:

  • familiarity with a scripting language
  • to be strongly motivated for a super-cool project

If you want to work on this project, but you think that you do not match some the required skills, we can give you some preliminary exercise to help you fill in the gap.

Status: Available

Supervision: Pasquale Davide Schiavone, Florian Zaruba

Contact Information

Contact Davide Schiavone davide@openhwgroup.org and Florian Zaruba zarubaf@iis.ee.ethz.ch

Professor

Luca Benini

↑ top

Meetings & Presentations

The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.

Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details confer to [1].

Retrieved from "http://iis-projects.ee.ethz.ch/index.php?title=Heroino:_Design_of_the_next_CORE-V_Microcontroller&oldid=6386"