Beyond the commercial module

Executive summary

A CPU module or System on Module turns the most complex part of an embedded design into a controlled, reusable platform. When architecture, hardware, and software are engineered together, the module can shorten derivative-product schedules, isolate high-speed design complexity and create a planned path for performance or processor upgrades.

The commercial benefit does not come from miniaturization alone. It comes from deliberate product partitioning, measurable requirements, early risk retirement, production test coverage and lifecycle governance. A successful program therefore treats the SoM as a product platform rather than only as a printed circuit board.

Business drivers

• Reuse a stable compute platform across multiple products and carrier boards.

• Reduce repeated high-speed memory and processor design effort in derivative programs.

• Enable controlled upgrades when performance, connectivity, or software requirements evolve.

• Improve supply resilience through component lifecycle analysis and qualified alternates.

• Create consistent security, diagnostics, provisioning, and field-update mechanisms.

Key success factors

When a CPU or SoM approach fits

An SoM approach is most valuable when several products share a common compute need, the product requires high-speed memory or interfaces, time to market matters, or the processor is expected to evolve during the product family life. A custom SoM may be preferable to a commercial SoM when form factor, cost at scale, environmental limits, security control, certification evidence, or supply strategy justify the non-recurring engineering investment.

What customization should achieve

Customization should solve clear product constraints. It should not be pursued simply to replace a commercial module. The design case is strongest when the product needs a particular combination of interfaces, mechanical envelope, thermal behavior, security ownership, environmental performance, lifecycle control, or unit economics that standard modules cannot meet efficiently.

The customization baseline is captured in a module requirements specification and interface control document. These become the common reference for the SoM, carrier board, enclosure, Board Support Package (BSP), manufacturing test, and future product variants.

Requirements and technology selection

Processor selection should follow workload and product constraints, not headline core count. Requirements are translated into measurable budgets for compute, memory bandwidth, boot time, power, thermals, interfaces, latency, safety partitioning, security, cost, and longevity.

Selection criteria

A weighted decision matrix can compare candidate processors and module architectures. Benchmarks should use representative software and I/O paths because vendor reference figures rarely reproduce the final workload, thermal designhardware, or memory configuration.

Hardware development

Hardware development begins with block architecture, interface allocation, and power-tree definition. Schematic and layout reviews then focus on the failure mechanisms most likely to affect first-pass success and long-term reliability.

Core engineering activities

• Processor, Double Data Rate (DDR) memory, nonvolatile memory, power management integrated circuit (PMIC), clock, reset, and boot-mode design.

• Pin multiplexing, voltage-domain checks, and carrier-interface definition.

• Power sequencing, rail monitoring, brownout behavior, and low-power-state support.

• DDR topology, impedance control, length matching, and post-layout timing analysis.

• Signal and power integrity analysis for PCIe, USB, Ethernet, MIPI, and display paths.

• Thermal modeling, heat-spreader strategy, sensor placement, and throttling limits.

• Debug access, boundary scan, test points, programming paths, and recovery mechanisms.

• Design-for-manufacture, assembly, test, reliability, and service considerations.

Module interface definition

The connector specification is a controlled design artifact. It defines signal direction, voltage, impedance class, reference planes, reserved pins, power delivery, sequencing, hot-plug restrictions, mechanical datum, mating cycles, and carrier-design rules. Reserved and migration pins protect future processor variants.

Board support software and platform enablement

Software enablement should start before fabrication using vendor evaluation kits, emulation where available, and reusable platform components. This overlaps BSP work with board development and exposes boot-chain, driver, and middleware risks earlier.

Yocto Project or Buildroot may be used for embedded Linux image construction depending on product needs. The choice should reflect reproducibility, package governance, customization depth, maintenance capacity, and compliance obligations rather than team familiarity alone.

Cybersecurity by design

Security requirements affect hardware selection, boot architecture, manufacturing, and field support. The objective is a verifiable chain of trust from silicon to application, with controlled ownership of device identity and update keys.

• Hardware root of trust, protected key storage, and unique device identity.

• Verified or secure boot with anti-rollback policy and controlled debug access.

• Signed and optionally encrypted firmware and software update packages.

• Least-privilege services, hardened configurations, and protected credentials.

• Software Bill of Materials (SBOM) generation, vulnerability monitoring, and time-bound remediation workflow.

• Secure manufacturing provisioning with separation of development and production keys.

• Recovery behavior that preserves availability without bypassing authenticity controls.

Repeat threat modeling when interfaces, deployment environments, or update mechanisms change. Confirm security claims through configuration review, negative testing, penetration testing where appropriate, and traceable evidence.

Verification and qualification

Verification progresses from individual rails and boot stages to complete system workloads. Each test has defined preconditions, instrumentation, acceptance limits, and retained evidence. The qualification plan is tailored to product standards, environment, and customer obligations.

Prototype stages

A practical program often uses engineering validation, design validation, and production validation builds. Entry and exit criteria prevent unresolved prototype limitations from silently becoming production risk. Pilot units should use production-intent materials, processes, firmware, and test coverage.

Typical deliverables

• Product requirements and system architecture specification.

• Processor selection study and hardware design package.

• Interface control document and carrier-board design guide.

• Bootloader, BSP, drivers, platform services, and build environment.

• Security architecture, provisioning flow, and software bill of materials.

• Verification plans, procedures, reports, and requirement traceability.

• Manufacturing package, programming tools, test strategy, and pilot support.

• Lifecycle plan, release process, and knowledge-transfer package.

Conclusion

A customized CPU or SoM delivers value when it is built around the real needs of the product family. The design must balance performance, form factor, interfaces, power, thermals, security, manufacturability, cost, and long-term support. Treating these as one engineering problem avoids late compromises between the module, carrier board, and software platform.

Mindteck can support the lifecycle from requirements and architecture through hardware development, BSP and driver enablement, verification, manufacturing readiness, and sustained engineering. The scope and ownership model can be tailored to the selected processor, product environment, compliance needs, and production volumes.