[discussion] Upstreaming an HPMicro bare-metal RISC-V MCU backend

[willChuai]

🚀 The feature, motivation and pitch

Hi ExecuTorch maintainers,

We're working on ExecuTorch support for HPMicro RISC-V MCUs and would like to
discuss the right upstream path before preparing PRs.

HPMicro is an MCU vendor shipping RISC-V microcontrollers such as the HPM5xxx
and HPM6xxx series. Some devices, including HPM6750-class parts, include packed
SIMD instructions through the RISC-V P extension. The public SDK is available
at github.com/hpmicro/hpm_sdk.

We currently have ExecuTorch running in the HPM SDK on HPMicro evaluation
boards. The platform startup code, linker scripts, device drivers, memory
configuration, and PAL implementation remain part of the HPM SDK runtime
environment.

The upstream-facing scope we would like to discuss is:

1. An ExecuTorch integration path for building/linking ExecuTorch from the
   HPM SDK environment (we're inclined to mirror the existing
   zephyr/CMakeLists.txt integration shape unless a different pattern is
   preferred).
2. RISC-V P-extension optimized int8 kernels for HPMicro-class MCUs.
3. Any backend/delegate structure, registration, tests, and documentation that
   ExecuTorch maintainers would expect for such acceleration support.

Proposed upstream path

One possible split is:

1. Start with an RFC or skeleton that defines the expected upstream structure
   for HPMicro/RISC-V P-extension acceleration support.
2. Add the minimal build/link integration needed for ExecuTorch to be consumed
   from the HPM SDK environment.
3. Add RISC-V P-extension optimized int8 kernels incrementally, with tests.
4. Agree on the validation requirements before expanding operator coverage.

Please let us know if a different split would fit the project better.

Scope

The intended ExecuTorch-side scope is:

• HPMicro/RISC-V P-extension acceleration support for int8 inference.
• Optimized kernels for common operator categories such as arithmetic,
  activation, comparison, matrix multiplication, and potentially
  convolution-related paths where appropriate.
• Build/link integration following the upstream ExecuTorch structure.
• Tests and documentation expected by maintainers for this type of support.

Validation

We would like to understand the minimum validation expected for an initial
proposal. Target execution for HPMicro devices would run in the HPM SDK
environment, since that is where the board startup, linker scripts, drivers,
memory setup, and PAL live.

For upstream review, would maintainers expect host-buildable kernel/backend
tests first, target execution evidence from the HPM SDK environment, simulator
coverage, a self-hosted runner, or another validation path?

Questions

1. Is HPMicro/RISC-V P-extension acceleration support a direction the project
   would consider upstreaming?
2. What upstream structure would maintainers prefer for this work?
3. Should we start with an RFC/skeleton before sending implementation PRs?
4. Which parts, if any, should live in ExecuTorch versus remain in the HPM SDK?
5. What is the minimum validation bar for the initial proposal?

Thanks for your time.

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

[luhenry]

P extension is clearly an interesting path of development for RISC-V. It's more adapted for smaller cores than RVV which can be quite hard to implement efficiently. It would fit well with the kind of target that ExecuTorch is targeting.

Where I'm missing knowledge and experience is at which level of the stack it should be integrated. RVV is integrated through XNNPACK, would it make sense for P to follow the same path? For anyone contributing to XNNPACK, what has been the success/easiness in pushing for RVV / RISC-V specific changes to upstream? Or how much work and how easy to upstream to ExecuTorch is it to add another backend? cc @GregoryComer @digantdesai

[digantdesai]

Thanks for the RFC @willChuai . Couple of things,

• In ExecuTorch for Embedded MCUs (Cortex-M) we do not use XNNPACK and have a operator library based on CMSIS. But it can be different for RISC-V, @rascani's call.

• AFAIK, xnnpack is accepting RVV code, I do see some recents PRs for RV32(https://github.com/google/XNNPACK/pulls?q=sort%3Aupdated-desc+is%3Apr+RVV), not sure about ext-p which is somewhat specific to embedded IIUC.

@luhenry - Working with XNNPACK folks - dsharlet - has been great, but we haven't contributed much RVV code TBH. :)