Skip to main content

v2n-m1-deepx-inference

DEEPX DX-M1 NPU bring-up plus a single inference through <alp/inference.h> on a V2N-M1 SoM.

This is the in-repo half of the V2N-M1 DEEPX integration story. The customer-side half — the DEEPX dx_rt runtime and its Linux PCIe driver, pulled from DEEPX-AI — sits outside the SDK because it ships under DEEPX's customer-only licence.

Source: examples/v2n/v2n-m1-deepx-inference/.

:::warning Silicon status: unverified There is no bench data behind this page. The DEEPX NPU is not available under any Zephyr-side emulator, so HiL is the only path to verification — and it gates on a V2N-M1 board file landing in alp-zephyr-modules, a test rig hosting a real V2N-M1 EVK, and the customer-side dx_rt integration.

Today the example ships one native_sim row where every backend call lands on the documented NOSUPPORT contract, plus a build_only: true V2N-M1 row. It flips to a positive-path scenario when the rig exists. :::

What it shows​

  1. PCIe mux + DEEPX power-rail bring-up. The V2N supervisor's power-management module responds to the board's DEEPX_PWR_EN_REQ rising edge, brings up the DA9292 CH2 = 0.75 V DEEPX rail, then asserts the DEEPX core enable. This happens automatically on SYS_INIT, before the example's main() runs — there is no board.yaml-level wiring for it.
  2. The one-call bring-up API. deepx_dxm1_bring_up() in the chips/deepx_dxm1/ host driver wraps the PI3DBS12212 PCIe mux routing plus the M1_RESET release into a single call. See the note below about what the example actually does.
  3. Inference handle open via the portable surface. backend = ALP_INFERENCE_BACKEND_DEEPX_DXM1, format = ALP_INFERENCE_MODEL_DXNN. Under the hood the SDK dispatches to the DEEPX dx_rt runtime via header bindings; the runtime itself is pulled in by the customer.
  4. One alp_inference_invoke() + result print.

:::note What main() actually calls main() prints its stage-1 line but does not itself call deepx_dxm1_bring_up() — the rail and mux come up through the supervisor's SYS_INIT hook. The one-call API is documented in <alp/chips/deepx_dxm1.h> and is what your own app would call; this example inherits the sequence rather than driving it. :::

The portable-surface point​

The whole app is <alp/inference.h> calls. Only two lines name DEEPX at all — .backend and .format in the config struct. The same surface is what aen-npu-inference uses to reach the Ethos-U85: same open / get_input / invoke / get_output shape, different backend enum.

src/main.c ships an 8-byte k_placeholder_model — not a real model. Replace it with your own DXNN-compiled model (use DEEPX's dxcom host compiler to produce a .dxnn from an ONNX source) before flashing.

board.yaml​

som:
  sku: E1M-V2M101  # V2N-M1 variant with DEEPX DX-M1 NPU

preset: e1m-x-evk

cores:
  a55_cluster:
    os: "off"
  m33_sm:
    app: ./src

chips:
  - deepx_dxm1    # host driver: PCIe mux + M1_RESET sequencer
  - da9292        # PMIC for the DEEPX 0.75 V rail
  - pi3dbs12212   # PCIe mux

diagnostics:
  log_level: info

The inference dispatcher set comes from V2M101's capabilities: block (drp_ai: true + deepx_dx: true) rather than a peripherals: list. DEEPX dispatches via the Linux PCIe driver, so under Zephyr the dispatcher emits a NOSUPPORT stub — real DEEPX inference happens on the customer's Yocto image via dx_rt, selected per-handle by alp_inference_open(.backend = DEEPX_DXM1, ...).

Expected output​

native_sim — every backend call returns NOSUPPORT on the host-emulated path, and the example reports it cleanly:

[deepx] v2n-m1-deepx-inference flagship
[deepx] stage 1: PCIe mux + power_mgmt bring-up (supervisor-side)
[deepx] stage 2: opening DEEPX inference handle
[deepx]   open returned NULL: last_err=-8
[deepx]   (expected under native_sim and on builds without dx_rt)
[deepx] done

On a working V2N-M1 with dx_rt present, stages 3–5 would print tensor counts, then the output tensor's size and dtype. No such run has been captured.

Getting the DEEPX runtime​

git clone https://github.com/DEEPX-AI/dx_rt modules/dx_rt
git clone https://github.com/DEEPX-AI/dx_rt_npu_linux_driver modules/dx_rt_driver

Both are under DEEPX's customer-only licence — see the SDK's vendor-partnerships doc for the full story and what falls on the customer to integrate.

See also​

Questions about this page? Discuss in Community Forum