Skip to main content

E1M™ Open Standard

E1M is an open specification for small-form-factor, AI-capable, machine-processable module-on-module products. The standard is published by Alp Lab AB under CC BY-SA 4.0 so any party can design conformant SoMs and carriers.

The canonical source of truth is the alplabai/e1m-spec repository.

Two form factors​

Form factorOutlinePad countLGA pitchAudience
E1M35 × 35 mm3120.8 mmMCU-class compute with on-chip NPU (AEN, i.MX 93).
E1M-X45 × 65 mm4960.8 mmMPU-class compute, dual GbE, PCIe, MIPI CSI lanes (V2N).

Both form factors share the same family of signal classes. E1M-X adds higher pad density to expose additional controllers (more PCIe ports, more MIPI CSI lanes, parallel LCD, etc.) than fits on E1M.

What the specification fixes​

For each form factor the standard defines:

  • The mechanical envelope — outline, height, component-placement areas.
  • The electrical interface — power input, voltage rails, reset, boot-strap, electrical characteristics.
  • The complete pinout — every pad's coordinate, its default function, and the signal classes it may carry under the alternative-function policy.
  • The conformance criteria for SoMs and carrier boards.
  • A machine-readable JSON pinout (Loom v1 format) validated by a published JSON Schema.

Pad-to-signal assignments are specified at the default-function level, plus GPIO as a universal secondary on every digital pad. Anything beyond default-plus-GPIO — silicon-specific alternate functions — is declared by the per-SoM manifest and falls outside E1M conformance.

Mandatory on-module components (§6.5, added in v1.1)​

Every conformant SoM SHALL integrate, on the module itself, the following components — they are not optional and cannot be DNI'd by the SoM vendor:

ComponentRequirement
Ethernet PHYAt least one PHY (and a second when the SoC supports two MACs), connected over SoM-internal RGMII / RMII. Carrier-side ETH*_* pads are post-PHY differential MDI, not raw MAC signals.
Wi-Fi 6 + BLE 5.4 combo radioMandatory 2.4 GHz and 5 GHz operation; 6 GHz operation is optional.
CAN transceiverOne per CAN group the SoM exposes. Carrier-side pads are bus-level CANxH / CANxL.

§7.3.2 (Antenna), §7.3.6 (Ethernet), §7.3.14 (CAN) reference §6.5 explicitly. The antenna populating rule tightened from v1.0's "MAY populate any subset" to "SHALL populate the bands the on-module radio supports".

§9.1 SoM conformance adds clause 5. Mandatory on-module components referencing §6.5.

This is a normative addition relative to v1.0; it does not change the pinout itself. v1.0-conformant SoMs (AEN family, V2N, V2N-M1) are also v1.1-conformant — all of them already satisfy the new clause.

What it does not cover​

  • The internal design of any SoM beyond §6.5's mandatory components (silicon choice, additional on-module support components, firmware). SoM vendors publish their own per-SoM manifests.
  • Per-SoM peripheral mappings beyond the default and GPIO secondary functions.
  • Carrier-board reference designs.

Per-SoM manifests​

Every conformant SoM publishes a per-SoM manifest declaring which E1M pads it routes and the silicon behind them. In ALP Lab's case, these live under metadata/e1m_modules/<MPN>.yaml in the alp-sdk repo. A third-party SoM vendor publishes its manifest wherever it likes; the format is documented in STANDARD.md Annex C.

The ALP SDK's loader consumes the per-SoM manifest at build time to:

  • generate <alp/soc_caps.h> so capability checks happen at *_open time;
  • emit the right Kconfig / CMake / Yocto config from the user's board.yaml;
  • compile in only the chip drivers the SoM actually populates.

Conformance​

A module is E1M-conformant when every clause of the spec's §9 holds for the applicable role (SoM or carrier board). Carrier boards are conformant when they wire only signals declared by the spec on the pads they consume, and when the mechanical and electrical interfaces match.

Versioning​

The form factor uses major.minor versioning.

  • A major bump is required for any backwards-incompatible pad change — removing a pad, narrowing a pad's allowed signal set, or shifting a pad's coordinate.
  • A minor bump is permitted for additions only — populating a previously-reserved pad or adding an alt-function entry to an existing pad.
  • A patch bump (v<major>.<minor>.<patch>) covers errata, doc fixes, and corrections that don't change the normative spec.

Current release: v1.1.1. Latest minor: v1.1.

Release history​

TagDateWhat changed
v1.02026-05Initial release. AEN family + V2N / V2N-M1 silicon mapping; Annex A section placeholders.
v1.0.12026-05Annex A: canonical SKU names from the per-family datasheets.
v1.0.22026-05Annex A + examples: corrected V2N silicon part numbers.
v1.0.32026-05Examples: enriched V2N-M1 manifest routes with Renesas BGA pin annotations.
v1.12026-05Minor. Added on-module connectivity SHALL clause + GD32G553 supervisor-MCU detail.
v1.1.12026-05-10Org move to alplabai/e1m-spec; internal URL fixups. No normative changes.

The authoritative tag list lives in the spec repo at alplabai/e1m-spec/releases.

Resources​

Questions about this page? Discuss in Community Forum