The Practical Guide to Product Development with SiPs
Most articles about System-in-Package devices stop at the definition. This one starts where the definition ends: at the point where you have a product to ship, a small team to ship it with, and a decision to make about how much of the system you want to design yourself.
A System-in-Package (SiP) puts the processor, DRAM, power management, boot memory, oscillator, and the surrounding passives into a single BGA that mounts on your board like any other component. That changes the shape of a hardware project more than it changes the electronics. Whole phases get shorter, some disappear, and a few new questions show up that you would not have asked in a discrete design.
This guide walks through a SiP-based product from the first architecture decision to production, phase by phase, with the specific things to do and watch for at each stage. It is written for hardware and embedded engineers evaluating or starting a SiP-based design.
Phase 0: Decide Whether a SiP is the Right Call
Before you pick a part, be honest about the constraints that actually drive your project. A SiP is the right answer surprisingly often, but it is not the right answer always, and the decision is easier when you make it on purpose.
A SiP tends to win when one or more of these is true:
- Board area is tight. A processor, DDR, PMIC, and passives that would normally cover a substantial patch of PCB collapse into a package as small as 9 mm x 14 mm. If you are fighting for millimeters, this is the whole argument.
- The team is small, or hardware and software are the same people. DDR routing, power sequencing, and PMIC configuration are the parts of a discrete design that take the most expertise and the most respins. The SiP vendor has already done them, validated them, and characterized them.
- You cannot afford a respin. Depending on the design, a board spin can add significant engineering, fabrication, assembly, and schedule costs. Integrating the processor, memory, and power infrastructure inside the SiP reduces the number of high-risk circuits that need to be implemented on the PCB.
- You need to scale without redesigning. A System-on-Module (SoM) is a fine way to prototype, but it carries a per-unit premium (a second PCB, connectors, and often hand assembly) that becomes painful at volume. A SiP is built on semiconductor packaging lines and assembled with standard pick-and-place, so the design you prototype is the design you ship at 100 units or 100,000.
A discrete design is still the better path when you need a memory configuration or power architecture the SiP family does not offer, or when your volume and margins justify the engineering investment to squeeze out every cent of BOM. If that is you, the SiP vendor will tell you so; a good one would rather lose the socket than have you fight the part.
Practical tip: Make this decision with a real BOM and a real schedule, not a hunch. Price the discrete design including the respin you will probably need, and compare it with the SiP design including the one you probably will not.
Phase 1: Architecture and Part Selection
Once you have decided on a SiP, part selection is mostly about matching the processor family to your software and I/O needs, then choosing the level of integration you want. Octavo offers SiP families with different processors, integration levels, and package options:
| Family | Processor | What is integrated | Package |
|---|---|---|---|
|
OSD32MP15x |
ST STM32MP15x (dual Cortex-A7 + Cortex-M4) |
Up to 1 GB DDR3, STPMIC1, EEPROM, MEMS oscillator, passives |
18 x 18 mm, 302-ball BGA, 1 mm pitch |
|
OSD32MP2x / OSD32MP2x-PM |
ST STM32MP25x |
From 1 GB DDR4, STPMIC2, EEPROM, oscillators, passives (PM: essential passives only) |
21 x 21 mm, 437-ball / 9 x 14 mm, 500-ball |
|
OSD62x / OSD62x-PM |
TI AM62x |
From 1 GB DDR4, power management, EEPROM, oscillator, passives (PM: essential passives only) |
21 x 21 mm, 437-ball / 9 x 14 mm, 500-ball |
|
OSD335x / OSD335x-SM / C-SiP |
TI AM335x (Cortex-A8) |
Up to 1 GB DDR3L, TPS65217C PMIC, EEPROM, passives (C-SiP adds up to 16 GB eMMC) |
27 x 27 mm, 400-ball / 21 x 21 mm, 256-ball |
|
OSDZU3 |
AMD Zynq UltraScale+ MPSoC ZU3 |
Up to 2 GB LPDDR4, 2x PMIC, LDOs, EEPROM, QSPI flash, 2x oscillators, passives |
40 x 20.5 mm, 600-ball BGA |
Three questions decide the choice:
- Which software ecosystem do you want to live in? The processor inside a SiP is the same silicon you would buy discretely, so you inherit the vendor’s Linux distribution, SDK, and community (OpenSTLinux for STM32MP, TI’s Processor SDK for Sitara, PetaLinux and Vivado for the Zynq MPSoC). Pick the ecosystem your software team is already productive in.
- How much do you want integrated? The full-integration parts bring the PMIC and oscillator inside, so power design on your board is reduced to an input rail and a handful of external capacitors. The -PM variants integrate the processor, memory, and essential passives in a much smaller footprint and leave power management to you, which makes sense when you already have a system power architecture or need the absolute minimum footprint.
- What memory do you actually need? Memory density is fixed at order time, not at layout time, so size it for the product’s life, not for the first firmware build. Most families offer more than one density in the same footprint, so you can move up without a layout change.
Practical tip: Read the datasheet's pin list against your I/O plan before you commit. SiPs expose most of the processor's pins, but a few are consumed internally by the PMIC, EEPROM, or oscillator. Find those now, not during schematic review.
Phase 2: Schematic Design
This is the phase where the SiP changes the most. In a discrete design, the schematic for the processor core, DDR, and power tree is the bulk of the work and the bulk of the risk. With a SiP, that work is a single symbol. What remains is the part of the design that is actually specific to your product.
You still own:
- Power input. Choose the input configuration the datasheet supports for your rail (for a typical fully integrated part this is a single 5 V-class input to the internal PMIC), budget in-rush current, add the external bulk and decoupling capacitance the datasheet calls out, and decide your I/O voltage domain (usually 1.8 V or 3.3 V).
- Reset and boot configuration. Pull-ups on reset, and the boot-mode pins strapped for your boot source (SD, eMMC, NOR flash, USB or UART for recovery). Make the boot pins configurable with resistor footprints or jumpers on the first revision; you will thank yourself during bring-up.
- Clocks you add. The main oscillator is inside the package. A 32 kHz crystal for the RTC is typically external if you need it, and it can be left unpopulated if you do not.
- Peripherals and connectivity. USB, Ethernet, display, camera, storage, and the sensors and connectors that make the product yours. This is normal work, and it is the work you would rather be doing.
- Debug and test access. A JTAG header, a console UART, and test points on every power rail and control signal. Cheap on revision A and painful to add later.
Use the vendor’s schematic checklist as a gate, not a suggestion. Octavo publishes one for each family, and every item on it corresponds to something that has bitten a customer. Then consider Octavo’s Hardware Design Review Service before you release the board to fab: a paid, line-by-line review of your schematic or layout by engineers who have seen hundreds of designs on the same part. Against the cost of a board spin, it is cheap insurance.
Practical tip: Route the SiP first and route it exactly as the layout guide shows, then fit the rest of the board around it. Improvising a fanout on a 400- to 600-ball part is the fastest way to waste a week.
Phase 3: PCB Layout
Layout is where discrete designs get expensive. Length-matched DDR routing, controlled impedance, and a dense processor fanout push you toward six, eight, or more layers with HDI features, and a stackup like that costs real money at every volume.
A SiP was designed specifically to avoid that. The high-speed memory interface never leaves the package, so the signals that reach your board are the ones you can route with ordinary rules.
The following layout considerations illustrate what that looks like in practice:
- Escape routing is deliberately shallow. On the 1 mm-pitch OSD32MP15x, almost all signal balls sit in the outer three rows of the BGA, so two 5 mil / 5 mil traces fit between adjacent pads and the entire device can be fanned out without buried or micro vias.
- Standard vias are enough. The layout guides show fanouts using a conventional 12 mil drill / 24 mil pad via, with 10/18 or 10/16 vias as an option when you want to tighten the design. You do not need an HDI fab.
- Fewer layers. Because the memory bus and power tree are internal, many designs can reduce the number of PCB layers required compared with an equivalent discrete implementation, helping lower board complexity and cost.
- Power is pours, not a tree. Route the input rail and the SiP’s regulated outputs as copper pours with adequate via stitching, and place the external decoupling capacitors close to the balls they serve. That is most of the power layout.
The 1 mm-pitch families are friendly to almost any fab; the 0.5 mm-pitch -PM parts are still routable on standard processes but reward a conversation with your fab about their preferred via and trace geometry before you start. For each package, begin with the corresponding layout guide and adapt the design to your board’s requirements.
Phase 4: Prototype and Bring-Up
Here the SiP changes the sequence of the project, not just the effort. In a discrete design, nothing runs until your first board comes back and the DDR is proven. With a SiP, the processor, memory, and power have already been validated together, and a development board with the same part on it is available on day one.
That lets you split the work:
- Software starts immediately. Put a development board (for example the OSD32MP1-RED, which ships with a Debian image, or the OSDZU3-REF with its PetaLinux distribution) in front of the software team the week the project starts. Bring-up of the OS, drivers, and application happens in parallel with your board design instead of after it.
- Hardware bring-up gets short. When your first board arrives, the questions are about your peripherals, your connectors, and your boot configuration. They are not about whether the memory trains. Octavo’s customers commonly report bring-ups shortened by six weeks or more relative to an equivalent discrete design.
- Breakout boards de-risk the odd cases. A breakout like the OSD32MP1-BRK or OSD62-PM-BRK brings the SiP’s pins to headers so you can prove a sensor, a display, or a radio on the bench before you commit it to your layout.
Plan revision A as a real product candidate, not a science experiment. Because the risky circuits are already proven, it is realistic for the first board to be close to final, and many teams go to production on revision B.
Phase 5: Software and System Integration
The most underrated benefit of a SiP is what it does not do to your software: it does not change anything. Because the silicon is the vendor’s standard processor, the board support package, device tree, bootloader, and kernel are the vendor’s standard ones. You are customizing a mainstream Linux distribution for your peripherals, not porting an operating system to a novel part.
A few things that keep this phase smooth:
- Start from the SiP vendor’s reference device tree for the development board and subtract what you removed rather than building up from the bare processor.
- Use the integrated EEPROM. It is a convenient place for board revision, serial number, and calibration data that the bootloader can read before your application starts.
- Get power management right early. The integrated PMIC is already configured for the processor’s sequencing; your job is to decide sleep states and wake sources for your product and test them on the development board before your own hardware exists.
- Lean on the community. The forums for each SiP family, and the much larger communities around the underlying STM32MP, AM62x, AM335x, and Zynq MPSoC devices, have already answered most first-time questions.
Phase 6: Production and Lifecycle
A SiP is a single line item on your BOM, sourced through normal distribution, and placed by any contract manufacturer with a standard SMT line. That has a few consequences worth planning around:
- Simpler assembly. Dozens of placements (processor, DRAM, PMIC, inductors, capacitors, oscillator) become one. Fewer placements means fewer defects, faster AOI, and less rework. Octavo cites average manufacturing cost reductions of 55% for SiP-based boards.
- Simpler sourcing. One part number instead of a dozen, from a vendor whose job is keeping that part in stock. In a memory-constrained market like 2026’s DDR shortage, buying DRAM already inside a package you have designed in is materially less risky than qualifying alternates at the last minute.
- A design that scales. Because there is no module, no connector, and no second PCB, your unit cost does not carry a premium that you need to design out later. The pilot build and the volume build are the same design.
- Long lifecycle. SiPs built on industrial processors inherit the industrial longevity programs of those processors. Confirm the lifecycle commitment for the specific family you choose and document it in your product’s risk register.
Talk to your contract manufacturer early about the package. A 1 mm-pitch, 300- to 600-ball BGA is routine for any competent CM; a 0.5 mm-pitch -PM part is also routine for most but worth confirming, along with their X-ray inspection capability for BGA joints.
The Pitfalls that Still Catch People
A SiP removes a lot of risk, but it does not remove judgment. The mistakes we see most often:
- Skipping the checklist. Nearly every first-revision issue traces back to an item that is on the vendor’s schematic checklist.
- Hard-strapping the boot pins. Leave them configurable on revision A.
- Starving the input rail. Underestimating in-rush or skimping on bulk capacitance produces intermittent boot failures that look like software bugs.
- Improvising the fanout. Follow the layout guide. It exists because the alternatives were tried.
- Treating the dev board as optional. It is the cheapest schedule acceleration in the project.
- Sizing memory for the demo. Choose the density for the product you will be supporting in five years.
Put Engineering Effort Where It Matters
The practical case for a SiP is not that it makes hardware design easy. It’s that it lets you spend your design effort where your product is actually different: the sensors, interfaces, enclosure, and software that your customers see. The processor core, memory, and power tree are solved problems; a SiP lets you treat them that way.
If you are starting a new embedded Linux product and want to see what this looks like on your specific requirements, talk to an Octavo engineer. We will tell you plainly whether a SiP is the right fit, and if you want a formal check before you release to fab, our Hardware Design Review Service goes through your schematic or layout line by line.
