What does a custom carrier board do?
A carrier board connects a compute module to the rest of a product. It may provide power conversion, field transceivers, connectors, protection, storage connections and control functions. The exact work depends on what the module already supplies and what the installation requires.
The project extends beyond placing connectors around a module. Mechanical constraints, signal integrity, software configuration, manufacturing and service access interact. A connector moved late in the project can affect routing, enclosure tooling and the cable harness. Capture those dependencies while they are still inexpensive to change.
If the platform decision is still open, begin with the SoM versus single-board computer guide. If the design includes AI inference, validate the intended model and sensor path before freezing the compute module.
What to include in the design brief
| Input | Information to provide | Why it changes the design |
|---|---|---|
| Compute module | Exact part, revision, memory/storage variant and supported BSP | Defines electrical, mechanical and software boundaries |
| Interfaces | Count, electrical standard, data rate, connector, isolation and cable length | Determines transceivers, protection, routing and validation |
| Supply | Nominal voltage, operating range, startup and disturbance requirements | Defines conversion, sequencing, protection and thermal work |
| Mechanics | Board outline, height limits, mounting, connector positions and enclosure model | Constrains placement, cooling and assembly |
| Software | Operating system, boot/update requirements and peripheral support | Defines BSP, driver and application integration work |
| Validation | Operating environment, applicable tests and measurable acceptance criteria | Defines equipment, prototypes, test time and evidence |
| Production | Pilot quantity, expected volumes, service model and manufacturing deliverables | Influences sourcing, test fixtures and change control |
Mark unknowns explicitly and assign each an owner. For example, “four cameras” leaves open the interface, sensor, cable length, synchronisation and simultaneous operating modes. An initial discovery stage can resolve those uncertainties before a fixed implementation scope is agreed.
A practical design and validation process
- Requirements and feasibility. Confirm the module, interface allocation, available software and major risks. Produce an agreed block diagram and acceptance outline.
- Schematic and component review. Define the power tree, protection, clocks, resets and interfaces. Review component availability and alternatives before layout.
- Layout and manufacturing review. Resolve stack-up, placement, routing constraints, mechanical fit, assembly access and test points.
- Prototype procurement and assembly. Check fabrication data and component substitutions, then record the as-built configuration of each board.
- Bring-up and software integration. Verify power and startup before exercising interfaces and the application workload. Track issues against board and software revisions.
- Validation and handover. Run the agreed tests, close issues and deliver the release data and supporting evidence defined in the project scope.
Use the module manufacturer's design guide and bring-up checklist for the selected part. Vendor references can identify requirements that are easy to overlook, but instructions for a different module or generation are not interchangeable. The NVIDIA checklist in the references is an example of how hardware and software checks are documented for a particular ecosystem.
What determines carrier-board NRE cost?
Non-recurring engineering covers work performed to create and validate the design. A useful quotation separates that work from prototype components, PCB fabrication, assembly, fixtures, external testing and recurring production. Agree which of these are included, optional or charged separately.
| Cost driver | Question to resolve before a quote |
|---|---|
| Interface complexity | Are interfaces already supported, or do they need new circuitry and drivers? |
| High-speed layout | Which signals impose stack-up, impedance and validation requirements? |
| Power and protection | What supply conditions and field disturbances must the complete product tolerate? |
| Mechanical constraints | Is the outline flexible, or must the design fit a fixed envelope and harness? |
| Software scope | Does the work include BSP adaptation, drivers, recovery and update support? |
| Prototype iterations | How are expected revisions, retesting and scope changes handled? |
| Qualification and production | Which formal tests, fixtures and manufacturing documents are required? |
A bare “PCB design” price is difficult to compare with a complete product-development quotation. Request a deliverable list, assumptions, exclusions, acceptance criteria and change process. That makes it possible to compare proposals without assuming that missing work is included.
How should the timeline be planned?
Build the schedule around dependencies. Requirements approval precedes the design freeze; fabrication and component availability determine when assembled prototypes can arrive; a hardware change may require another manufacturing cycle before a test can be repeated. Software can proceed in parallel on a development platform only where that platform represents the final hardware closely enough.
At each milestone, state the deliverable, owner, review decision and next dependency. For example: approved schematic; released manufacturing package; powered prototype; verified interfaces; application test report; production release.
A credible delivery estimate needs a defined scope and a component-supply check. Separate engineering effort from elapsed lead time and include time for review, procurement and an agreed iteration allowance. Treat prototype availability and production qualification as separate milestones.
Define acceptance before the first prototype
Turn requirements into observable tests. Instead of “the gateway works,” specify the interface modes, traffic pattern, duration, allowed loss and the log or measurement that records the result. Instead of “AI is fast,” define the model, input, accuracy threshold, sustained throughput and acceptable output delay.
- Document startup, shutdown, recovery and behaviour after an interrupted update.
- Exercise the required interfaces together, rather than only one at a time.
- Run the intended workload long enough to evaluate the relevant thermal operating condition.
- Verify the agreed service and production-test procedures.
- Keep the board revision, firmware and software image attached to every test result.
For mechanical and power considerations, see our rugged fanless computer design note. For a neural-network workload, the RK3588 NPU testing guide provides a starting point for separating model performance from complete-system performance.
Agree the handover package
Specify the formats and rights for schematics, PCB layout, manufacturing outputs, bill of materials, assembly instructions, software, programming instructions and test fixtures. Define which editable sources are delivered, which third-party components have separate licences, and who maintains the design after acceptance. These are project terms to agree, not assumptions that follow automatically from paying NRE.
A useful release also records known limitations, approved substitutions, unresolved risks and the procedure for requesting changes. That information helps the manufacturing and service teams distinguish a controlled revision from an undocumented variation.
Custom carrier-board questions
Can a reference carrier be copied unchanged?
It can be an engineering starting point where its licence permits, but the new installation still needs electrical, mechanical, software and manufacturing validation. Check that every referenced design applies to the exact module and revision.
Is BSP work included automatically?
Only if the agreed scope includes it. State who owns boot configuration, peripheral support, operating-system integration and long-term updates in the project brief.
What is enough for a first discussion?
A block diagram, module preference, interface list, supply details, enclosure constraints, target quantities and intended pilot date are a useful starting point. Include what remains undecided so the first conversation can focus on those risks.
Connect PCB design to embedded Linux bring-up
Custom PCB design and embedded-system software are interdependent. A board-support package (BSP) needs to match the selected system-on-module, power sequencing, pin allocation and attached peripherals. Resolve these interfaces before layout so that hardware and embedded Linux bring-up can proceed against the same configuration.
For an edge AI product, include the intended camera or sensor path in early feasibility work. A working processor module does not prove that the complete acquisition and inference pipeline will meet the required latency. Capture driver availability, memory needs and test evidence in the project brief.
Review fanless industrial PC design constraints
Technical references
- NVIDIA: module adaptation and hardware/software bring-up checklists
- Digi: embedded-system development starting points
The process above is a project-planning framework. Electrical design rules must come from the selected module's current technical documentation.
Bring your interface list.
Send the module preference, connectors, supply, enclosure and pilot quantity. We can turn them into a scoped carrier-board and embedded-software discussion.
