Raw dependency graph data (JSON)

Edge Impulse Inferencing SDK (C++)

Author: Ludovic HENRY ludovic.henry@qti.qualcomm.com
Date: 2026-09-08
Readiness: orange
Optimization level: absent
Scope: RISC-V (riscv64/linux) support status for Edge Impulse Inferencing SDK (C++)
Audience: Technical leadership, resource allocation strategy
Verification policy: Every claim is cross-referenced to a primary upstream source. Items that could not be verified against a second source are marked [NEEDS VERIFICATION].

1. Project Overview

Edge Impulse Inferencing SDK (C++) is a portable, source-vendored C++ library for digital signal processing and machine learning inference on embedded and edge devices, distributed as the edgeimpulse/inferencing-sdk-cpp GitHub repository. It contains the on-device implementation of processing and learning blocks generated by the Edge Impulse Studio platform, and is meant to be symlinked or vendored into a consuming firmware/application project rather than built or installed standalone, per the repository’s own README: “If you want to develop locally the easiest is to grab the example-standalone-inferencing… example applications… then symlink this repository in.”

Governance: There is no independent governance body. This is a corporate SDK owned by Edge Impulse Inc., which was acquired by Qualcomm Technologies, Inc. in March 2025. The repository has no MAINTAINERS, OWNERS, GOVERNANCE, PLATFORMS.md, SUPPORT.md, or CONTRIBUTING.md of its own; the only such files present are vendored third-party ones (porting/espressif/ESP-NN/CONTRIBUTING.md from Espressif, porting/ethos-core-driver/SECURITY.md from Arm). The repo functions as a largely one-way squash-mirror of Edge Impulse’s internal monorepo: of 136 total commits, 63 (the entire recent history, all “SDK version” bumps) are pushed by an automated bot account, edgeimpulse-firmware-uploader[bot], with no visible individual PRs or review trail on GitHub.

Corporate maintainers (all Edge Impulse/Qualcomm employees, by commit count): Jan Jongboom (Edge Impulse co-founder/CTO, 50 commits), Mateusz (mateusz@edgeimpulse.com, 16), Yan (yan@edgeimpulse.com, 3), Ross (ross@edgeimpulse.com, 1), Arjan Kamphuis (2), and one external/customer contributor, Raul (raul@nobi.io, 1). There is no independent or external maintainer group.

License: BSD-3-Clause-Clear for Edge Impulse’s own code, with vendored third-party components under their own licenses (CMSIS: Apache-2.0; TensorFlow: Apache-2.0; kissfft: BSD-3-Clause; ESP-NN: Apache-2.0; ethos-core-driver: Apache-2.0; gemmlowp/flatbuffers/ruy: Apache-2.0).

Community culture on new ports: No formal tiering or acceptance process is documented. Edge Impulse’s public docs (docs.edgeimpulse.com/reference/inferencing-sdks/cpp-inferencing-sdk) state, regarding the config.hpp/numpy.hpp target-optimization hooks: “If you want to add optimizations for a new target this would be a good place to start. We welcome contributions!” - the only public invitation found; no CODEOWNERS gating or documented review workflow exists in the repo itself, consistent with its role as a mirror of an internal monorepo.

2. Port History and Upstreaming Timeline

Date Event Source
2025-08-08 Commit 0481b35 (“SDK version: v1.74.8”) vendors an updated copy of Espressif’s esp-dsp library, introducing the only two __riscv string occurrences in the repo’s entire git history - generic #if defined(__XTENSA__) \|\| defined(__riscv) compiler guards, not a deliberate RISC-V port Local clone of edgeimpulse/inferencing-sdk-cpp, commit 0481b35
N/A No dedicated RISC-V port directory has ever been added under porting/ (26 subfolders exist: ambiq, android, arduino, brickml, ceva-npn, clib, espressif, ethos-core-driver, himax, himax-we2, iar, infineon-psoc62, mbed, mingw32, particle, posix, raspberry, renesas-ra, seeed-vision-ai, silabs, sony, stm32-cubeai, synaptics, ti, zephyr - none is riscv-specific) porting/ directory listing
N/A No riscv64-related issue, PR, or commit ever opened in this repository (confirmed via search_issues, search_pull_requests, search_commits, search_code, all returning 0 relevant results) GitHub search across edgeimpulse/inferencing-sdk-cpp

Key contributors: None specific to RISC-V exist. A community, non-Edge-Impulse project, arijitdas123student/esp32c3-ei (“Support for running Edge Impulse on RISC-V HW”), demonstrates third-party RISC-V enablement on ESP32-C3 (RV32IMC), but this is unaffiliated with the upstream repository and out of scope for this report [NEEDS VERIFICATION - not independently examined].

Is it fully upstream? No RISC-V port exists upstream at all - not in progress, not partial, not merged. There is no tracking issue, no in-flight PR, and no maintainer statement of intent to add riscv64 support.

3. Upstream Support Tier

Formal tier policy: None documented. No PLATFORMS.md, no tiered-support matrix, no release-blocking architecture list exists in the repository.

Evidence:

  • No CI of any kind exists in the repository - no .github/workflows, no .gitlab-ci.yml, no Jenkinsfile, no .cirrus.yml (confirmed by full-tree clone inspection at HEAD 7e1cb5747f4b87e2e59a12c907e2a35c929008c2, tag v1.95.0).
  • No GitHub releases exist for this repository, for any architecture: the releases page reads “There aren’t any releases here.”
  • No official binaries exist on PyPI, Ubuntu, Debian, Fedora, or Arch for any architecture (verified: PyPI JSON API returns HTTP 404; Ubuntu 26.04/resolute package search returns no match).
Architecture Upstream CI build Upstream CI test Upstream official binary
amd64 no (no CI exists at all) no no
arm64 no (no CI exists at all) no no
riscv64 no no no

Support-tier status is identical across all architectures because this project has no CI and no release pipeline whatsoever - it is not that riscv64 is treated worse than amd64/arm64; none of them receive automated build/test/release validation. The distinguishing factor for riscv64 specifically is the complete absence of any named porting/ target, whereas amd64/arm64/ARM Cortex-M targets are explicitly supported through named porting directories (posix, mbed, stm32-cubeai, etc.) and architecture-conditional optimized code paths (CMSIS-NN, NEON).

4. Technical Architecture and RISC-V-Specific Subsystems

The SDK contains several architecture-specific acceleration subsystems. None has a RISC-V-specific implementation.

Component arm64 (Cortex-A/NEON) Cortex-M (CMSIS-NN/DSP) x86_64 riscv64
Hand-tuned NN kernels (CMSIS-NN) full full scalar fallback missing
Hand-tuned DSP/math kernels (CMSIS-DSP) full (NEON path) full scalar fallback missing
SIMD vector intrinsics (__ARM_NEON/__aarch64__ in 3 files) partial n/a incidental only (4 files, inherited from upstream kissfft/TFLite, not EI-authored) missing (zero RVV intrinsics found anywhere, including vendored ruy/gemmlowp/TensorFlow trees)
Named porting/ target directory n/a (covered generically) via mbed/stm32-cubeai/etc. n/a missing (no porting/riscv* directory among 26 named ports)
CI / build validation none (no CI exists) none (no CI exists) n/a missing (no CI of any kind in the repo)

Dispatch logic (classifier/ei_classifier_config.h, dsp/config.hpp): acceleration macros such as EI_CLASSIFIER_TFLITE_ENABLE_CMSIS_NN and EIDSP_USE_NEON are set to 1 only when the compiler defines ARM Cortex-M target macros or __ARM_NEON/__aarch64__. Every other architecture, including riscv64, silently falls through to the generic portable C++ scalar reference implementation. There is no #error on unrecognized architectures and no riscv64-specific branch anywhere in the source tree.

Only RISC-V-adjacent code found (2 files, both third-party vendored, not Edge-Impulse-authored):

  • porting/espressif/esp-dsp/modules/common/include/dsp_common.h - #if defined(__XTENSA__) || defined(__riscv) (cycle-counter macro selection for Espressif’s RV32IMC-based ESP32-C3/C6 chips)
  • porting/espressif/esp-dsp/modules/common/include/dsp_platform.h - identical guard for esp_cpu.h inclusion

These are 32-bit embedded-target compiler guards inherited from Espressif’s vendored esp-dsp library, unrelated to riscv64/Linux and unrelated to any acceleration path - they only affect which cycle-counter intrinsic is called.

ESP32-C3 note: dsp/config.hpp (line 114) and classifier/ei_classifier_config.h (line 85) both list CONFIG_IDF_TARGET_ESP32C3 (an Espressif RISC-V chip) among the macros that enable EIDSP_USE_ESP_DSP/EI_CLASSIFIER_TFLITE_ENABLE_ESP_NN, but the actual hand-written assembly kernels under porting/espressif/ESP-NN/src/**/*.S and porting/espressif/esp-dsp/modules/fft/**/*.S (27 .S files total) are all suffixed _esp32s3/_aes3/_ae32/_arp4 - Xtensa-only. There is no _esp32c3/RISC-V-variant kernel; ESP32-C3 builds fall through to the plain portable C/C++ reference implementation with no ISA-specific optimization even on that RISC-V target.

5. Build System, Cross-Compilation, and Toolchain

No riscv64 build documentation, toolchain file, Dockerfile, or CMake support exists in this repository. Confirmed by full-tree inspection of the clone at HEAD 7e1cb5747f4b87e2e59a12c907e2a35c929008c2:

  • No BUILDING.md, INSTALL, docs/building.md, or docs/cross-compilation.md exists - there is no docs/ directory at all.
  • No top-level CMakeLists.txt exists. Only 3 CMakeLists.txt files exist in the whole repo, all deep in vendored/porting code (cmake/zephyr/CMakeLists.txt, porting/espressif/ESP-NN/CMakeLists.txt, porting/ethos-core-driver/CMakeLists.txt); none reference riscv.
  • No cmake/riscv64.cmake or toolchain file exists. cmake/ contains only cmake/utils.cmake, cmake/add_source.cmake, cmake/zephyr/CMakeLists.txt.
  • Zero Dockerfiles exist anywhere in the repository (search_code filename:Dockerfile returns 0 results).
  • No GCC/Clang minimum-version documentation, no -DUSE_X=OFF style build flags, and no QEMU usage notes exist for any target, riscv64 included.

This repo is not a standalone buildable project - it is a source/header SDK meant to be dropped into a consumer project such as edgeimpulse/example-standalone-inferencing (Desktop) or edgeimpulse/example-standalone-inferencing-mbed, where the actual CMake invocation, toolchain, and Docker/QEMU setup would live. Those consumer repos were out of scope for this report and were not checked.

Feature-selection flags are C preprocessor #defines set via compiler -D flags (not CMake options), none riscv64-specific: EI_CLASSIFIER_TFLITE_ENABLE_CMSIS_NN (ARM only), EI_CLASSIFIER_TFLITE_ENABLE_ARC (Synopsys ARC), EI_CLASSIFIER_TFLITE_ENABLE_ESP_NN/_S3/_P4 (Espressif Xtensa), EI_CLASSIFIER_USE_FULL_TFLITE.

6. Feature Coverage and Gap Analysis vs arm64 and amd64

Feature arm64 amd64 riscv64
Compiles at all yes (untested by CI) yes (untested by CI) unverified - falls through generic porting/posix path, which contains no arch-specific code, but this path has never been built or tested by anyone traceable in the record
Accelerated NN kernels (CMSIS-NN) yes scalar fallback scalar fallback (identical to amd64’s situation)
Accelerated DSP/FFT yes (NEON) scalar fallback scalar fallback (identical to amd64’s situation)
Named porting target yes (via generic + mbed/stm32 paths) not explicitly named no (not a recognized target at all)
CI validation none (no CI exists) none (no CI exists) none (no CI exists)
Official release binary none (no releases exist) none (no releases exist) none (no releases exist)

Functional gaps: riscv64 is not a recognized target anywhere in the SDK - there is no porting/riscv* directory, and the generic porting/posix layer that a Linux riscv64 target would presumably use is untested and unverified for this architecture specifically. No evidence exists that anyone has ever built this SDK on riscv64.

Performance gaps: Identical to amd64’s situation for NN/DSP acceleration (both fall back to scalar C++ since CMSIS-NN/DSP is ARM Cortex-M only and ESP-NN is Xtensa only) - riscv64 is not disadvantaged relative to amd64 here, since amd64 also gets no hand-tuned acceleration in this SDK. The gap is specifically vs. arm64/Cortex-M targets, which get hand-tuned NEON/CMSIS kernels.

Security hardening gaps: Data not available - no security-hardening documentation (ASLR, stack protector, CFI configuration) exists in the repo for any architecture.

NaN/floating-point semantics issues: Data not available: searched GitHub issues for “riscv nan floating point” (0 results) and general web search for RISC-V floating-point correctness issues specific to this SDK (none found).

7. CI/CD Infrastructure

No riscv64 CI exists - because no CI exists at all, for any architecture. Verified by direct file-tree inspection of the clone at HEAD 7e1cb5747f4b87e2e59a12c907e2a35c929008c2:

  • .github/workflows does not exist; there is no .github directory whatsoever.
  • No .gitlab-ci.yml, Jenkinsfile, .cirrus.yml, .travis.yml, .circleci/, azure-pipelines.yml, .drone.yml, appveyor.yml, or bitbucket-pipelines.yml exists anywhere in the tree.
  • The only YAML file in the entire repository is porting/espressif/ESP-NN/idf_component.yml, an ESP-IDF component dependency manifest (package metadata), not a CI pipeline definition.

No RISE runners are referenced anywhere (there is no CI to reference them in). No hardware, QEMU, or cloud-VM CI execution occurs for this repository on any architecture.

  amd64 arm64 riscv64
CI exists no no no
Builds tested no no no
Release-blocking no (no releases exist) no no
RISE runners used no no no

8. Distribution and Release Status

No official binaries exist for riscv64, or for any other architecture. Verified across every channel checked:

  • GitHub Releases: the releases page states “There aren’t any releases here” - zero releases exist for any architecture, so no filename anywhere can contain “riscv64.”
  • PyPI: https://pypi.org/pypi/edge-impulse-inferencing-sdk-(c++)/json returns HTTP 404 - no such package exists on PyPI at all.
  • RISE Python wheel builder (https://gitlab.com/api/v4/projects/56254198/packages/pypi/simple/): the package is not listed among the 89 riscv64-built wheels present.
  • Ubuntu 26.04 (resolute): package search for multiple plausible name variants returns no match; the architecture-filter list shown on the search page does not include riscv64 as an option for a nonexistent package.
  • Debian, Fedora, Arch RISC-V: no evidence of packaging found; not checked exhaustively as the project publishes no source releases at all to package from.

What a user must do to get a working binary today: There is no binary to obtain. A user would need to (1) clone the source repository directly, (2) integrate it into a consumer build (e.g. example-standalone-inferencing), and (3) attempt a from-source build targeting riscv64 via the generic porting/posix path - an untested, unverified, unsupported path with no confirmation it has ever succeeded.

9. Dependencies

Dependency Role riscv64 build riscv64 test riscv64 release Community
TensorFlow Lite Micro (vendored @ c903b4607821a03c36c17b0befa2535c7dd0e066) Core ML inference engine Builds only via unofficial fork; upstream has no riscv64 target (only riscv32_generic, Tier 2, nightly QEMU, reference kernels only) No riscv64 CI upstream (riscv32 nightly only, not PR-gated) Zero GitHub releases (nightly only); PyPI nightlies are manylinux_2_28_x86_64-only Open PR #3280 adds RVV (Zve32x) kernels for riscv32 only, unreviewed since Jan 2026; does not cover riscv64
ruy (third_party/ruy) SIMD int8/float32 matmul backend Builds via scalar kStandardCpp fallback - no RVV path, no RUY_PLATFORM_RISCV macro No upstream CI beyond org-level CodeQL libruy-dev packaged for riscv64 in Ubuntu 26.04/resolute (confirmed via project graph query) Zero riscv64 issues/PRs in google/ruy
gemmlowp (third_party/gemmlowp/fixedpoint) Legacy fixed-point matmul fallback Builds via scalar fallback; explicit ARM NEON/x86 SSE headers but no RISC-V detection No riscv64 CI (project in maintenance mode, superseded by ruy) libgemmlowp-dev packaged for riscv64 in resolute (confirmed) Effectively zero riscv64 issues in google/gemmlowp
FlatBuffers (third_party/flatbuffers) Zero-copy .tflite/EI model deserialization Pure C++, no SIMD/JIT - architecture-agnostic No upstream riscv64 CI; Debian sid confirms libflatbuffers-dev built on riscv64 (rv-osuosl-02) Upstream GitHub releases ship zero riscv64 flatc binaries; Debian/Arch RISC-V packages fill the gap Zero riscv64 GitHub issues in google/flatbuffers
CMSIS-NN/DSP (vendored from ARM-software/CMSIS_5 @ 4d378e81968c6bec5441a42885b24db7cf189bca) Hand-tuned ARM Cortex-M SIMD kernels N/A - ARM Cortex-M only by design; compiled out entirely on riscv64 N/A N/A Not applicable to riscv64 by design; not a blocker
kissfft (dsp/kissfft) FFT/FFTR kernels for MFCC/spectral DSP feature extraction Pure portable C, architecture-agnostic No known riscv64-specific failures libkissfft-dev packaged for riscv64 in resolute (confirmed) None found
Synopsys ARC MLI (third_party/arc_mli_package) ARC EM/HS NPX-optimized NN kernels N/A - Synopsys ARC-specific, compiled out on non-ARC targets N/A N/A Not a RISC-V-relevant dependency

The SDK’s own critical dependencies (FlatBuffers, ruy, gemmlowp, kissfft) are individually available as riscv64 packages in Ubuntu 26.04 (resolute), and none blocks a riscv64 build in principle - meaning the absence of riscv64 support in the Edge Impulse SDK itself is not a transitive-dependency blocker, but a gap in the SDK’s own port/CI/release process (no named porting/riscv* target, no CI, no releases at all).

11. Known Bugs and Active Issues

ID Title Status Severity Notes
- - N/A - no riscv64-related issues or PRs exist - Confirmed via search_issues (queries: “riscv”, “riscv64”, “RISC-V”, “rv64”, “riscv64 performance”, “riscv bug”, “riscv nan floating point” - all 0 results) and search_pull_requests (same query set, all 0 results) against edgeimpulse/inferencing-sdk-cpp

No correctness bugs, no performance issues, and no open tracking issues exist for riscv64 in this repository, because no riscv64-related activity of any kind has ever been recorded there.

12. Objections and Upstream Blockers

Stated objections: None found. No maintainer has stated an objection to riscv64 support; equally, no maintainer has expressed intent to add it.

Technical blockers:

  • No CI infrastructure exists to validate any riscv64 port even if contributed (no .github/workflows at all - a riscv64 job could not be added without first building CI from scratch for every architecture).
  • No named porting/riscv* target exists to receive a contribution.
  • The repository is structured as a near-one-way mirror of Edge Impulse’s internal monorepo (63 of 136 commits are automated “SDK version” bumps from a bot account) - suggesting new architecture ports likely originate internally at Edge Impulse/Qualcomm rather than through external GitHub PRs, though this is inferred from repo mechanics, not a stated policy [NEEDS VERIFICATION].

Organizational blockers:

  • Edge Impulse Inc. was acquired by Qualcomm Technologies, Inc. in March 2025. Qualcomm Technologies, Inc. is itself a RISE Premier Member, but Edge Impulse has no separate/direct RISE membership, and no RISE blog post, wheel-builder listing, or riseproject-dev GitHub org repo references this project.
  • The only mention of this project within RISE-adjacent infrastructure is an unactioned entry in this project’s own tracking queue (project-reports/.queue.yml in riseproject-dev/sw-ecosystem) - not evidence of funding, sponsorship, or in-progress work.

Acceptance probability: Low in the near term absent external funding or a direct Qualcomm-internal initiative, given: (1) no CI exists to validate any contribution, (2) the repo shows minimal evidence of external community PR activity generally (bot-dominated commit history), and (3) the public invitation to contribute (“We welcome contributions!”) is generic and untargeted at RISC-V specifically.

13. Readiness Assessment

  • Color: orange (no upstream CI of any kind, no distro/third-party package, no GitHub releases for any architecture)
  • Release provider: none
  • Optimization level: absent - the SDK contains hand-tuned SIMD/assembly acceleration for ARM (CMSIS-NN/DSP, NEON) and Xtensa (ESP-NN), but zero RISC-V-specific optimized code exists anywhere in the tree (no RVV intrinsics, no arch/riscv/ directory, no .S assembly files for RISC-V). riscv64 falls through to the generic portable C++ scalar reference implementation, identical to any other unlisted architecture. ISA extensions that would close the gap: RVV (vector NN/DSP kernels analogous to CMSIS-NN/NEON paths) and, secondarily, Zba/Zbb for scalar bit-manipulation speedups in the reference kernels.
  • Justification: The repository has no .github/workflows directory and no CI configuration of any kind (repository tree at HEAD 7e1cb5747f4b87e2e59a12c907e2a35c929008c2), publishes zero GitHub releases for any architecture (releases page: “There aren’t any releases here”), and is not distributed on PyPI (404) or in Ubuntu 26.04/resolute for any name variant. Because upstream CI is entirely absent (not merely absent for riscv64) and no distribution channel ships this project at all - not even an unpatched distro build - the distribution floor cannot apply, and the base color is orange. The optimization-purpose cap (absent RISC-V code, since the project does contain ARM/Xtensa hand-tuned kernels but none for RISC-V) independently caps at orange as well, so both paths converge on the same result.
  • Pending work that could change the grade: None identified. No open PRs, no RISE involvement, and no tracking issue exists for a riscv64 port of this specific SDK. The only related upstream activity is in a transitive dependency, TensorFlow Lite Micro, where PR #3280 adds RVV kernels for riscv32 (not riscv64) and remains unreviewed since January 2026 - this would not, even if merged, directly change this SDK’s own port status without additional integration work.

14. Investment Analysis

RISE has not funded or performed any work on this project specifically (confirmed: no RISE blog post, no riseproject-dev GitHub org repo, no wheel-builder listing, no RISE runner usage - see Sections 1 and 12). All work items below are therefore unclaimed.

14.1 Functional Enablement

The minimum bar for riscv64 to become a recognized target: add a porting/riscv64 (or generalize porting/posix) target, validate the SDK actually builds and runs correctly on riscv64 hardware/QEMU end-to-end (inference correctness against known model outputs), and get this validated in a consumer example repo (example-standalone-inferencing) since this SDK is not independently buildable.

14.2 Performance Optimization

Would require adding RVV-accelerated NN/DSP kernels analogous to the existing CMSIS-NN/CMSIS-DSP (ARM) and ESP-NN (Xtensa) paths - a substantial undertaking given CMSIS-NN/DSP alone represents ~14MB of hand-tuned ARM kernel source. A more efficient path may be to prioritize RVV kernel work in the upstream TensorFlow Lite Micro dependency (see PR #3280, currently riscv32-only) and let this SDK inherit acceleration transitively, rather than duplicating kernel work at the Edge Impulse layer.

14.3 CI/CD Infrastructure

Would require building CI from scratch for this repository (none exists for any architecture today), then adding a riscv64 build+test job - a two-stage effort since baseline CI does not exist to extend.

14.4 Ecosystem Enablement

Not applicable - Section 10 omitted per instructions; this is a standalone SDK library with no dependent package ecosystem (no PyPI package, no npm package, no plugin/extension ecosystem depending on it).

14.5 Summary Table

Area Work Item Effort (person-weeks) Owner Priority
Functional Add named porting/riscv64 target and validate build/inference correctness end-to-end (via a consumer example repo) 2-4 Edge Impulse/Qualcomm (upstream) or third-party contributor High
CI/CD Build baseline CI for the repository (none exists today, any architecture), then add riscv64 build+test job 2-3 Edge Impulse/Qualcomm (upstream) Medium
Performance RVV-accelerated NN/DSP kernels (direct SDK-level implementation) 15-25 (per comparable estimate in project-reports/reports/ruy.md for a similar SIMD kernel scope) Edge Impulse/Qualcomm (upstream), or via upstream TFLM RVV work Low (defer pending TFLM upstream RVV maturity)
Performance (alternative) Track/accelerate merge of TFLM PR #3280 (riscv32 RVV) and extend to riscv64, then integrate into this SDK 4-8 (integration only, assuming TFLM RVV work lands upstream) RISE / TFLM upstream + Edge Impulse integration Medium

15. Updates

(No updates yet - initial report dated 2026-09-08.)

16. References