Every product programme that outgrows a single MCU hits the same fork: put the compute on a standard module, or design it chip-down onto your own board. The module vendors will tell you modules de-risk everything. The design houses will tell you chip-down is cheaper at volume. Both are selling something.

Here is the decision the way we walk clients through it – what each standard is actually for, and the four questions that settle it.

What Each Standard Is Actually For

SMARC – an 82×50 mm (or 82×80 mm) module on a 314-pin edge connector, built around low-power Arm and x86 SoCs, with first-class camera (MIPI-CSI) and display (LVDS/eDP/MIPI-DSI) interfaces. SMARC is the default answer for HMI panels, vision devices, and battery-conscious Linux products in roughly the 2–15 W envelope. The ecosystem is broad, multi-vendor, and genuinely cross-compatible at the connector level – though never assume pin-mux compatibility between vendors without reading both hardware manuals.

OSM – the newest of the three module standards, and the one that changes the economics. OSM modules are solder-down LGA packages (no connector at all), in four sizes from 30×15 mm to 45×45 mm, designed to be placed by the same pick-and-place line as every other component on your carrier. No connector cost, no mechanical stack height, full assembly automation. OSM is what you choose when you want module-style sourcing and lifecycle management but BOM pressure rules out a connectored module. The trade: rework is hot-air territory, not a swap, which weakens the field-repair story.

COM Express – the x86 workhorse. Larger, hungrier, PCIe-rich, with Type 6 (graphics-led) and Type 7 (server/headless, 10 GbE) pinouts. It is the right answer when the workload is genuinely PC-class – heavy protocol conversion, on-prem analytics, legacy x86 software you cannot port. For new Arm-first designs it is rarely the starting point; its high-performance successor, COM-HPC, matters mainly at the edge-server end most embedded products never reach.

Chip-down – the SoC, DDR, and PMIC on your own board. Maximum integration, minimum unit cost, full mechanical freedom – and you now own DDR routing, power-tree bring-up, thermal validation, and the silicon’s lifecycle risk alone. The honest entry price is a senior hardware team and a programme that can absorb a respin.

The Four Questions That Settle It

1. What does the volume curve actually look like? A module carries a per-unit premium – commonly in the €25–80 range over the equivalent chip-down BOM, depending on class – but erases most of the compute-related NRE and months of schedule. Chip-down inverts that: high NRE, lowest unit cost. The crossover point varies by product, but the pattern is consistent: under ~10k lifetime units the module almost always wins; above ~50k chip-down usually wins if the team can execute it; between the two, the next three questions decide.

2. How long must the product live? Module standards exist so the compute can be revised without respinning the carrier. When the SoC goes end-of-life in year five, a module product swaps modules; a chip-down product runs a redesign. Under the ESPR’s repairability and durability scoring, that same separability is becoming a regulatory asset, not just a procurement one – a replaceable compute module is a ready-made repair and material-recovery argument. Note that OSM sits awkwardly here: lifecycle-managed like a module, but soldered like a chip.

3. Is there a real second source? The standards’ multi-vendor promise is real at the connector and mostly aspirational at the firmware. Migrating between two SMARC vendors still means a new BSP, new pin-mux validation, and weeks of carrier requalification. Treat “standard module” as cheaper vendor migration, not free vendor migration – and verify a genuine second-source module exists at your performance point before counting it as risk reduction.

4. Can your team carry the integration you are taking on? A SMARC carrier is a serious but bounded design task – no DDR, no core power tree. Chip-down moves all of that in-house. The honest self-assessment: a team that has not done DDR layout before should not learn on a programme with a ship date.

The Pattern That Works

Most of the programmes we see succeed follow the same arc: module for the first generation, chip-down only when volume proves it. Generation one ships on SMARC or OSM, the product finds its market, and the unit-economics conversation happens with real volume data instead of a forecast. The carrier-plus-module architecture also leaves the bring-up risk concentrated in your own peripherals rather than in the compute core – which is where a first-generation team should be spending its debugging budget.

The reverse arc – chip-down first to “save money at scale” at a scale that never arrives – is the most expensive pattern in embedded product development. The NRE is spent either way. The volume that justified it is the part that was a guess.

Choosing a compute architecture for a new programme?

The module-vs-chip-down call locks in your unit economics, lifecycle risk, and team load for the life of the product. We run it as a structured assessment against your real volume curve and team. Talk to an Embedded Architect →

Frequently Asked Questions

What is the difference between SMARC, OSM, and COM Express? SMARC is a connectored 82×50 mm (or 82×80 mm) module standard for low-power Arm/x86 designs with strong camera and display support. OSM is a solder-down LGA module standard optimised for cost and automated assembly. COM Express is a larger, x86-centric, PCIe-rich standard for PC-class workloads. They target different power envelopes and integration models rather than competing head-on.

At what volume does chip-down become cheaper than a module? The crossover depends on the module premium and the NRE your team would spend, but as a working pattern: below roughly 10,000 lifetime units the module nearly always wins, above roughly 50,000 chip-down usually wins if the team can execute DDR-class design, and the range between is decided by lifecycle, second-sourcing, and team capability rather than unit cost alone.

Are modules from different vendors really interchangeable? At the connector, largely. In practice, migrating vendors means a new BSP, pin-mux revalidation, and carrier requalification – weeks of work, not a drop-in swap. Standard modules make vendor migration cheaper, not free.

Does modular design help with EU compliance? A separable compute module strengthens repairability, upgradeability, and material-recovery arguments under the ESPR, and concentrates critical raw materials in a recoverable assembly. Solder-down OSM modules retain the lifecycle benefits but weaken the field-repair argument.