Alp SDK · v0.15.0 · released 2026-08-07

One declarative file. Heterogeneous build.

Same C/C++ API across Alif, Renesas, DeepX. Set the module SKU; the SDK produces a dual-image build for every heterogeneous SoM — Yocto on the A-cluster, Zephyr on the M-class companion, IPC stitched in. It runs on every E1M edge AI module and implements the open E1M standard.

§ The Alp SDK stack

Write once, run on any E1M module.

Alp SDK is the unification software layer for Alp Lab edge AI modules. A single C/C++ API works across every E1M SoM — present and future — wrapping each vendor's SDK on top of the chosen OS (Zephyr / Yocto / bare-metal). Single-OS or heterogeneous, the application surface stays identical.

◆ E1M platform

AI Framework

On-device inference

On-device runtimes

TFLM → Ethos-U Alif AEN (U55 all E3..E8; U85 on E4/E6/E8 — Transformer)TFLM → Ethos-U NXP N93 (U65)TFLM → DRP-AI3 (Renesas V2N)TFLM → DEEPX DX-M1 (V2M family)TFLM → CPU reference kernels

Model families

classificationdetection (YOLOv5/v8 on DEEPX + DRP-AI3)segmentationkeyword-spottingpose

Offline training only

TensorFlowPyTorch

↓trained model → deployable inference

Dev Tooling

Build, orchestrate, flash

v0.15.0

board.yaml v2tan CLI (build · run · flash · emit)tan doctor (host preflight)tan monitor (serial console)tan new-som (porting kit)west alp-quality (gate profiles → JSON/SARIF/JUnit)alp_orchestrate.py (fan-out + system-manifest)alp_project.py (per-core emit)portable-API conformance suiteVS Code extensionprogram_eeprom.pyper-OS dependency bootstrap

↓board.yaml → per-core build + flash

Alp SDK

One unified <alp/*.h> API

Peripherals

GPIO / I²C / SPIUART / PWM / ADCCAN / RTC / WDT / USB

Audio

PDM in (mics)I²S out + ampTAS2563

Camera

OV5640CAM_MUX

Inference

dispatcherEthos-U / DRP-AIDEEPX / CPU

IoT / BLE

Wi-Fi 6MQTTBLE 5.4

Security

MbedTLSPSA CryptoOPTIGA TM

Display / GUI

SSD1306 / 1331LVGLGPU2D / Dave2D

HW Info

EEPROM manifest (authoritative)hw_rev + serial<alp/hw_info>

DSP / Power

alp_dsp_* chain (FFT, FAC, IIR)<alp/power.h>

Heterogeneous IPC (v0.6 NEW)

<alp/rpc.h> framed RPMsg over OpenAMP<alp/system_ipc.h> auto-generated endpoint IDs<alp/mproc.h> mailbox · shared mem · hwsem

80 Tier-1 chip drivers + Tier-2 community

lsm6dsobmi323bmp581icm42670ina236tmp112tcal9538rv3028c724c128cc3501essd13xx…

User libraries (board.yaml libraries:)

ETLfmtnlohmann_jsondoctestLVGLMbedTLSCMSIS-DSPLittleFS

↓<alp/*.h> calls · RPMsg IPC bridges M-class ↔ A-class

Operating System

Per-core slice (cores: in board.yaml) · heterogeneous = peers on same SoM

Zephyr · M-class cores

Yocto · A-class cores

Bare-metal · no-RTOS

Bare-metal

↓per-core OS slice

Vendor SDK

We wrap each one

Alif Ensemble (AEN)Renesas RZ/V2NNXP i.MX 93DEEPX DX-M1

↓wrapped vendor HAL

Hardware + HAL

E1M open-standard form factor

E1M (35×35 mm) SoMsE1M-X (45×65 mm) SoMsE1M-EVK carrierE1M-X-EVK carriervendor HALs

Standalone firmware against <alp/...> headers, or alp-studio codegen — same API surface either way.

1. v1.0after first pilotPlanned

   Silicon-verified release · ABI freeze

   • ›HiL bring-up sweep across AEN + V2N101 + V2M101
   • ›ABI snapshot frozen — backwards-compat guarantee
   • ›Concurrent multi-NPU (DRP-AI3 + DEEPX) proven on V2M101
   • ›Mender OTA E2E on V2N101 fleet of N ≥ 3 boards
   • ›4 vertical reference apps end-to-end verified
2. v0.15.02026-08-07 · releasedShipped

   AEN801 dual-core flash release-blocker fixed · DRP-AI3 reachable from <alp/inference.h> · four real Yocto backends

   • ›Release-blocker: on E1M-AEN801 the M55-HP and M55-HE images both linked to slot0 0x80010000, so flashing both cores silently overwrote one image (#1069). Alongside it, alp_mproc_boot_core()’s image-residency precondition and a direction-specific M55-HP TCM-invalidation erratum are documented from E8 bench evidence (#1070), and a new aen-dualcore-he-master example (HE-master → HP-peer) is silicon-proven as of 2026-08-01
   • ›CONFIG_DCACHE=n is fixed across eight AEN dual-core / SRAM0-beacon examples that were silently exposed to cross-core cache incoherence, and five AEN examples stopped mis-reporting ALP_ERR_NOSUPPORT as an unreachable-in-practice SKIP (#1071)
   • ›The RZ/V2N on-die DRP-AI3 NPU is reachable from <alp/inference.h> as an opt-in backend (#1145), and libalp_sdk’s own link now refuses undefined symbols instead of deferring the failure to the consuming app
   • ›Real Yocto/Linux backends land for <alp/display.h> and <alp/i3c.h> (#1143, #1147) and for <alp/storage.h> and <alp/usb.h> (#1140, #1141) — the Linux leg of four portable classes that previously had a Zephyr backend only
   • ›Security and concurrency hardening: two path-traversal bugs in tan model build and in untrusted template catalogs (#1125, #1126); flash-backend path traversal plus script command injection (#1112, #1113); the CC3501E Wi-Fi/BLE/GPIO/OTA backends had shared one unlocked transport (#1116); five memory-safety defects in the AEN Zephyr drivers (#1119–#1122, #1124); signed-left-shift UB in SHA-256 word assembly (#1117); and an alp_handle_begin_close() busy-spin that could deadlock under priority scheduling (#1114)
   • ›ALP_CAP_HW_ETHERNET read false on V2N/V2M despite two 1 GbE ports (#1240). Two ADRs pin the surrounding stance: ADR 0023 keeps Ethernet out of <alp/*> (the portable contract is ALP_SOC_ETHERNET_COUNT plus the port identity and the rtl8211fdi PHY driver, not a new <alp/net.h>), and ADR 0024 keeps ADC, PWM, DAC, counter and qenc on V2N/V2M served exclusively by the GD32 IO-MCU bridge
   • ›Gate and tooling integrity: an hw_rev that exists but is status: reserved / tbd / status-less is now refused (#1025, the status half); scripts/gen_rzv2n_cm33_svd.py projects a cross-validated CMSIS-SVD register view for the RZ/V2N CM33 that Renesas ships no SVD for (#1029); test-all.sh had been running 1 of 34 required gate scripts on Windows (#1109); and the macOS and Windows CI legs can now actually fail the PR
3. v0.14.02026-07-29 · releasedShipped

   Portable I3C controller class · bootstrap facts as data · the hw_rev / SDK-version gate finally exists

   • ›New portable <alp/i3c.h> MIPI I3C Basic controller surface ([ABI-EXPERIMENTAL]): alp_i3c_open / write / read / write_read / close / capabilities, with a Zephyr backend over upstream i3c_dw.c on the Alif Ensemble E8 (lpi3c0). Controller init is bench-proven on E1M-AEN801 (Flow C RAM-run, 2026-07-25); a live transfer is still unproven. I3C joins the portable-API conformance suite
   • ›metadata/bootstrap.json and metadata/toolchains.json single-source the cross-platform bootstrap facts and the Zephyr-SDK toolchain pin as data, with prerequisites.install as the one place host-tool install commands are written (#949) — replacing the same facts hardcoded across several bootstrap scripts
   • ›The hw_rev / SDK-version compatibility gate now exists (#1019). The docs had been advertising a gate that had never been implemented; that claim was first removed, then made true — an out-of-range revision now raises SdkRevisionUnsupported and validate_board_yaml.py exits 3, and an hw_rev absent from the resolved table raises SdkRevisionUnknown (exit 4) instead of silently building against the wrong hardware
   • ›One first command: README.md and docs/getting-started.md now lead with tan bootstrap, matching tan’s own quickstart
   • ›Alif E8 silicon work: gpio11..gpio14 added to the peripherals dtsi so the RGB LED’s green and blue channels are reachable; a DesignWare GPIO functional-clock enable driver (gpio_clk_alif.c) and an OSPI0 clock-enable fix in flash_ospi_alif.c that had reproduced a bus fault on E8 (both ADR 0017 Tier-1.5); and E8 builds now default to the real SoC capability profile rather than the permissive one
   • ›Zephyr v4.4.0 → v4.4.1 patch bump; E8 SoC peripheral coverage extended to I3C, OSPI/HexSPI and managed-MDIO (build-only); Alif Ensemble peripheral counts re-ingested from the DFP with provenance recorded for counts that are inherited rather than audited (#936); and debug-probe identity (jlink_device, jlink_flash_device, pyocd_target) added to the Alif Ensemble SoC specs (#987)
   • ›Four V2N/V2M SoM manifests had promised a gd32_bridge firmware path that exists in no clone (#852) — the build now refuses cleanly when a GD32 bridge image is absent instead of failing later and further away
4. v0.13.02026-07-24 · releasedShipped

   CC3501E BLE GATT on real AEN silicon · Yocto power backend · Kconfig LSP feed

   • ›The CC3501E BLE GATT server is proven on physical E1M-AEN801 silicon (SW-DP 0x4C013477, persistent across a cold power-on reset): the aen-cc3501e-ble-gatt example drives bridge PING, alp_ble_open, a dynamic GATT service register, and advertise_start through the portable <alp/ble.h>. It is server-only — there is no BLE central on the bench, so end-to-end read/write against a peer stays HIL-deferred
   • ›Dynamic CC3501E GATT service registration replaces the fixed-demo stub — a new BLE_GATT_REGISTER (0x38) wire message carries a variable-length service/characteristic descriptor the firmware bounds-validates and registers at runtime, returning the attribute handles to the host
   • ›Runtime GATT server plus client read/write on the Zephyr BLE backend, proven host-side under native_sim (new ble_gatt_server test); the client read/write path is bench-deferred since native_sim ships no reachable BLE controller. Fixes a read-completion bug that timed out every successful client read
   • ›New Yocto/Linux power backend — request_sleep via /sys/power/state (freeze/standby/mem) plus an RTC wakealarm for a timed wake, registered beside the Zephyr / Alif-SE / GD32-supervisor backends. Real-board confirmation is a later bench step
   • ›The 31-byte legacy BLE advertising budget is now enforced centrally before backend dispatch, so an over-budget adv_config is rejected identically on Zephyr and CC3501E (found on AEN silicon, where a 15-char name plus one 128-bit UUID failed only on CC3501E)
   • ›New --emit kconfig projects a board-scoped Kconfig symbol menu for the VS Code prj.conf LSP, anchored to a cross-repo golden fixture with a conformance gate so tan-cli and the extension can’t drift; callback self-close deadlocks fixed across MQTT, Yocto CAN/GPIO, and CC3501E BLE

§ Examples

Real applications. Clone, build, run.