Embedded product engineering

One team for the full board lifecycle

High-speed PCB design for AI hardware, board and Linux bring-up, EMI pre-compliance, and hardware testing in CI. Four stages that usually mean four vendors and three handoffs.

BenchPod typical CI: emulate sensors and power rails by playing arbitrary analog waveforms into your target.

What we do

Four stages of the board lifecycle, one team

Integrating AI hardware — NPUs, accelerator modules and SoMs — is our specialty.

01

High-speed PCB design

Schematic, stackup and layout for boards that carry AI silicon: NPUs, accelerator modules and SoMs.

PCIe Gen4 / Gen5
LPDDR5
MIPI CSI-2
Controlled impedance
Length matching
Power integrity / PDN
HDI stackup

02

Bring-up and Linux BSP

First power-on through to a booting system: bootloader, device tree, drivers and a reproducible image.

U-Boot / SPL
DDR calibration
Device tree
pinctrl / pinmux
Kernel drivers
Yocto / Buildroot
Secure boot
OTA (RAUC / SWUpdate)
Booting devices from a known image →

03

EMI / EMC pre-compliance

Find the emissions problems on the bench, while a fix is still a layout change rather than a respin.

CISPR 32 / EN 55032
FCC Part 15
Radiated emissions
Conducted emissions
LISN
Near-field probing

04

Test, CI and iteration

Hardware-in-the-loop tests wired into your pipeline, so every change is measured on the real board.

Hardware-in-the-loop
pytest
GitHub Actions
Boot assertions
Power profiling
Your first HIL test →

Founders with more than 20 years in Linux, CI, CD and reliability engineering. Two decades of established software practice, brought to hardware.

Best practices that get skipped

None of it is controversial. It is just the first thing cut when a date slips.

What usually happens

  • The layout house does not talk to the firmware team.
  • Bring-up findings live in a notebook and are never measured again.
  • EMC is discovered at the accredited lab, after the layout is frozen.
  • CI stops at “it compiles.” The hardware regressions ship.

How we work instead

  • Design-for-test and EMC are schematic review inputs, before layout is frozen.
  • Bring-up becomes the first automated suite, and the baseline to regress against.
  • Pre-scans happen on the bench, months before the lab.
  • Every commit is flashed, booted and measured on the real board.

How we engage

Three ways to work with us

Take the full lifecycle, or bring us in for the stage that is blocking you.

The whole board

All four stages, from a blank schematic to a board under test in CI.

A single stage

A layout review, a Linux BSP, an EMC pre-scan, or the test rig on its own.

Rescue an in-flight project

A board that will not boot, will not pass EMC, or will not stay fixed.

Our test hardware

BenchPod

We built BenchPod because we kept rebuilding the same test rig from a Raspberry Pi and assorted adapters. It is not a prerequisite for working with us, and nothing we build for you depends on it.

Sensor sim
CAN
Analog I/O
Power control
Logic analyzer
FPGA
Python SDK
pytest

Resources

Technical write-ups from our own work

Where are you starting from?

A blank schematic, a board back from the fab, or a pipeline that stops at the build step. The first conversation is the same: what are you shipping, and how do you know it works?