Custom System-on-Module design
SMARC, OSM and LGA modules designed end to end — pin-out definition, DDR fly-by routing, power tree, fabrication package.
Most embedded products do not fail because the application software was hard. They fail because the compute platform underneath was the wrong shape — too big, too hot, unavailable in three years, or locked to a vendor whose roadmap moved.
A custom System-on-Module fixes the shape problem. It puts the processor, memory, power tree and the parts that are genuinely hard to route onto a small, reusable, qualified board — and leaves your carrier free to be simple, cheap, and specific to your product.
What we design
Modules to SMARC 2.1, SGET OSM in Size-S and Size-L, and LGA form factors for cost-sensitive builds — around Renesas RZ/V2L and RZ/V2M vision-AI parts, RZ/G2L for industrial HMI, RZ/N2L for TSN networking, and STM32MP2 on the ST side, together with the carrier boards and evaluation platforms that go with them.
Module design is a narrower discipline than general PCB work, and the difference between reading a standard and building to it shows up in specific places: pin-out compatibility across a family, drop-in upgrade paths between performance tiers, carrier migration, and the corners of a specification where a reasonable reading and the common reading diverge. Those are learned by doing, not by downloading the PDF.
Where the difficulty actually is
| Area | What has to be right |
|---|---|
| Memory | DDR4/LPDDR4 fly-by topology, write levelling, length matching to the vendor’s tolerance, and a stack-up the fabricator can actually hold |
| Power | Sequencing that satisfies the SoC’s power-up specification exactly, plus rail-by-rail transient headroom under AI inference load |
| Thermal | Junction temperature at the worst realistic ambient, not at 25 °C — with the carrier’s copper as part of the heat path |
| Standard compliance | Every pin that the standard defines, behaving as the standard defines it, so a customer’s existing carrier works |
| Longevity | Second-source footprints and a BOM that survives a shortage without a respin |
Vendor-neutral by construction
Design houses that sell modules recommend the modules they sell. That is not dishonesty, it is gravity. We have no catalog, so the trade study is real: your interface list, volume, thermal envelope, longevity requirement and unit cost target go in, and a ranked recommendation with the reasoning comes out. Sometimes that recommendation is “buy a module from a vendor, do not build one.”
Common questions
Straight answers
Should we design a custom module or buy an off-the-shelf one?
Buy off-the-shelf below roughly 1,000 units a year, unless you have a hard constraint an existing module cannot meet — a form factor that does not fit, an interface mix nobody offers, a 10-year availability guarantee, or a BOM cost target you cannot reach at a vendor's margin. Above that volume the NRE usually pays back inside the first production run. We will tell you honestly which side of the line you are on, because we have no module catalog to sell you.
SMARC or OSM — which standard should we pick?
SMARC 2.1 if you need PCIe, multiple display outputs and a connector you can service in the field; it is a board-to-board connector, so modules are replaceable. OSM if you want the module soldered down for shock and vibration, a lower Z-height, and no connector cost — the trade-off is that rework needs a reflow station. OSM Size-S suits MCU-class and entry MPU designs; Size-L carries the interface count of a full applications processor.
Are you tied to a particular silicon vendor?
No, and that is deliberate. We have no module line to protect, so the SoC recommendation follows your requirements: Renesas RZ for vision AI and industrial, ST STM32MP for cost-sensitive Linux, NXP i.MX and TI AM62 where the ecosystem or longevity program fits better. The trade study comes before the schematic.
Can you guarantee the module boots mainline Linux?
The hardware is designed so it can — correct boot-mode strapping, accessible debug, a memory map the vendor BSP expects, and no undocumented deviations from the reference design. We do board bring-up and validation through U-Boot to a Linux prompt. Deep BSP and kernel work beyond that we scope with a partner rather than overclaim.