Motor-Control SiP vs Discrete Power Design: What the Comparison Sheet Leaves Out
Quick Overview
Problem: The SiP-versus-discrete choice is usually settled on board area and part count — the two inputs that are easy to tabulate — while thermal concentration, safety architecture and lifecycle get decided by default.
Common failure points: A thermal budget built from the reference design’s conditions rather than the enclosure’s; safety functions assumed to sit inside the package; a power figure taken from a reference design and treated as a device limit; single-source exposure on a long production run.
Where it appears: EV coolant and oil pumps, HVAC blowers, thermal-management valves, seat and closure actuators, AGV and AMR drives, robot joints, e-mobility controllers.
Engineering focus: Measured losses and junction temperature at worst-case ambient, which safety functions the component actually covers, and how much of the design stays adjustable after the architecture is fixed.
The Decision That Looks Settled
Illustrative scenario, composed from recurring patterns rather than a single project.
A 12 V coolant pump node. Tight housing, almost no board area, no airflow. The integrated system-in-package wins the component review on every line: fewer parts, a much smaller board, a reference design with field-oriented control firmware already running.
Thermal validation comes later. At the top of the ambient range, under continuous duty inside a sealed housing, junction temperature sits higher than the model predicted — because the model inherited the reference design’s conditions, not the enclosure’s.
What happens next is the interesting part. The team still has real options: more copper, a denser via array under the package, a better thermal interface to the housing, a reduced switching frequency. What it does not have is the option it would have had with a discrete stage — repositioning individual MOSFETs, sizing each one’s copper to its own loss, or bolting a heatsink onto the switches.
That is the actual shape of this decision. Integration does not remove cooling options. It removes the freedom to place and size the power devices, and it concentrates the losses in one package. Everything downstream of that package remains yours to engineer; everything inside it does not.
Wrong Assumption
The assumption is that this is a sizing exercise: find the power level, find a part that covers it, compare footprint and BOM, commit.
That framing holds until something in the program moves — and something usually does. Duty cycle rises in validation. The node gets relocated and the ambient spec changes. A hazard analysis lands differently than scoping assumed. A customer adds Safe Torque Off. A part goes on allocation.
None of those are arguments against integration. They are arguments for knowing, before you commit, which of them you can still absorb and which force a board revision. The comparison sheet is quietly biased toward what it can tabulate: board area and part count fit in a column, and thermal concentration, safety responsibility and second-sourcing do not.
Four Motor-Control Architecture Options
Vendor language is the first source of confusion here. “SiP”, “SoC” and “integrated driver” are used loosely across datasheets for genuinely different things. Four options are worth separating.
| Class | Inside the package | Still external | Representative devices |
|---|---|---|---|
| Full motor-control SiP | MCU, supply, comms, gate driver and power MOSFETs | Shunts, caps, connector, sensors | Infineon MOTIX™ TLE9954QSW40-33 (Arm® Cortex®-M23, LIN, 5.5–29 V supply) |
| Control SoC / co-packaged controller | MCU, supply, comms, 3-phase gate driver | Power MOSFETs, shunts | MOTIX™ TLE987x / TLE989x (Cortex®-M3, 5.5–28 V); MOTIX™ TLE995x (Cortex®-M23, LIN, 5.5–29 V); MOTIX™ IMD700A / IMD701A (XMC1404 + 6EDL7141, 5.5–60 V) |
| Power-stage SiP | Half-bridge power devices + HV gate driver | MCU, supply, sensing, control | ST GANSPIN611 / GANSPIN612 (650 V GaN half-bridge, 9 × 9 × 1 mm QFN) |
| Discrete / modular | Nothing, or a power module co-packaging several switches with their substrate | Controller, gate drive supply, sensing, and in the discrete case the switches themselves | Gate driver + six MOSFETs; or SiC / IGBT power module |
Note that the three MOTIX SoC families do not share a core: TLE987x and TLE989x are Arm® Cortex®-M3 devices, while the newer TLE995x uses Cortex®-M23 at up to 40 MHz with LIN, 72 kB flash, ASIL B and TrustZone®. Treating them as one specification is a common error in secondary sources.
The middle class matters most and gets discussed least. A device that integrates the controller and gate driver but leaves the MOSFETs outside keeps the power devices selectable, placeable and individually coolable, while still cutting component count and supplying a firmware starting point. How much development that actually saves depends on the application.
What Full Integration Looks Like in 2026
Infineon introduced the MOTIX™ TLE9954QSW40-33 on 3 March 2026 as its first fully integrated automotive motor-control SiP. It combines an Arm® Cortex®-M23 at up to 40 MHz with 72 kB flash, 6 kB RAM, TrustZone®, a LIN interface, the power supply, a three-phase bridge driver and six OptiMOS™ 7 MOSFETs in a PG-LIQFN-58 package, on a 5.5–29 V supply. Infineon reports up to 30% fewer components and roughly 40% smaller boards against an equivalent discrete design, with AEC-Q100 Grade 0 qualification (−40 °C to +150 °C ambient) and ISO 26262 support up to ASIL B.
The widely quoted 150 W figure needs care. It comes from Infineon’s 150 W water pump reference design, and Infineon’s own material indicates higher power is reachable with improved cooling. It is a reference-design operating point under stated conditions — not a guaranteed continuous rating in any enclosure at any ambient. Treat it as a useful anchor for the class and derive your own limit from measured losses and junction temperature.
The LIQFN package is engineered to move heat from the MOSFETs into the PCB while holding parasitic inductance low enough to protect EMC performance at high switching frequency. The board beneath it still does real thermal work — which is exactly the point: the copper is yours, the package internals are not.
What the Discrete Path Still Buys
A discrete three-phase drive separates the power stage — six MOSFETs as three half-bridges — from the gate driver, commanded by an external MCU or DSC.
On board area, integration wins clearly, and the published comparisons are worth reading as individual examples rather than as a general rule. Monolithic Power Systems compares its integrated MPQ6541 — a 4.75–40 V automotive three-phase power stage with six 15 mΩ MOSFETs, 8 A continuous and up to 12 A peak for one second depending on thermal and PCB conditions — against an MPQ6533 pre-driver with discrete MOSFETs, and reports 130 mm² against 520 mm², a 75% reduction. In its product catalogue MPS frames a different comparison, 15 × 10 mm against 50 × 30 mm, a 90% reduction. Both are MPS measurements under MPS assumptions, on specific part pairs. They do not establish a savings range that transfers to an arbitrary drive.
What discrete buys back is control over the power devices. Each MOSFET can sit on its own copper pour, sized to that switch’s loss, or couple to a heatsink. ST’s EVALSTDRIVE101 — an STDRIVE101 gate driver with STL110N10F7 MOSFETs, 6 V to 75 V bus, up to 20 A rms — ships with a 75 × 74.6 × 15 mm heatsink, a thermal interposer and four M3 screws, and its user manual includes a section on mounting it. That is the option a discrete stage offers, and it is a design choice rather than a defect: a bolted heatsink is available precisely because the switches are outside the controller.
Integration also has a voltage range in practice. MPS places the practical ceiling for monolithic integrated drivers at roughly 80–100 V and about 15 A. Current automotive motor-control SiPs target 12 V architectures specifically — the TLE9954QSW40-33 runs on a 5.5–29 V supply, so a 48 V node needs a different device, not the same one at a higher rail. Above that range the power stage is built from discrete SiC or IGBT devices with standalone high-voltage gate drivers. Power modules from Infineon, Semikron Danfoss or ROHM consolidate those devices onto one substrate, but a module is a packaged power stage with the controller still outside it.
The GaN power-stage class sits alongside this rather than inside it. ST’s GANSPIN611 and GANSPIN612, launched in November 2025, put a 650 V GaN half-bridge and its gate driver in a 9 × 9 × 1 mm QFN for 110–230 V AC appliance and industrial loads. The widely cited 400 W figure belongs to ST’s three-phase reference design; ST’s own blog differentiates the parts, with the 270 mΩ GANSPIN612 around 300 W and the 138 mΩ GANSPIN611 above 400 W. There is no MCU in either package.
Hidden System Complexity
The chain that decides whether a motor node holds up in the field runs past the part number:
control algorithm → MCU compute and loop rate → gate drive and dead time → power stage losses → junction-to-case → case-to-board or case-to-heatsink → board copper, vias and thermal interface → enclosure and ambient → delivered shaft torque
Integration fixes two links in that chain — junction-to-case, and the physical arrangement of the switches — and concentrates all dissipation at one site. The links downstream stay adjustable. That is a narrower statement than “the thermal path is fixed”, and it is the accurate one.
The second chain is the one comparison sheets skip:
hazard analysis → ASIL or SIL target → required safety functions → what the component covers and documents → what the system must supply → certification evidence
A device supporting ISO 26262 up to ASIL B supports your element to ASIL B. It does not make your item ASIL B, and it does not by itself deliver Safe Torque Off. What it does supply — shutdown paths, diagnostics, independence claims, safety manual — is what determines how much the system has to add.
Failure Patterns
Pattern 1 — Thermal budget inherited from the reference design. The model uses the reference board’s ambient and copper, not the enclosure’s. The node passes on the bench and runs hotter in the product. The recovery is still available — copper, vias, interface material, switching frequency — but it is late, and the enclosure may already be tooled.
Pattern 2 — The ASIL target moves after the architecture is set. A node scoped as ASIL A is reassessed as ASIL B. The question this raises is not “does the component sit one level above the target” — decomposition distributes requirements across sufficiently independent elements, and does not require a component rated above the item’s goal. The question is whether the chosen architecture provides the independence the decomposition needs, and whether the component’s documented diagnostics and shutdown paths support the argument. An integrated package can make that argument harder to build, because access to the individual switches and to independent shutdown paths is limited by what the device exposes and documents — but it does not settle it.
Pattern 3 — Safe Torque Off arrives late. STO under IEC 61800-5-2 at SIL 2 or PL d has to be assessed concretely: what shutdown paths exist, how independent the channels are, what diagnostic coverage the component documents, and what the safety manual permits. Some integrated devices support a credible STO architecture with modest external circuitry; others do not. Package type is an input to that assessment, not the answer.
Pattern 4 — Supply disruption mid-programme. A discrete build can often second-source a gate driver or a MOSFET package — but the re-qualification effort scales with how much the substitution changes, and “drop-in” is rarely literal. An integrated build concentrates that risk in one part. Infineon publishes longevity commitments on these devices (the TLE9954QSW40-33 product page states availability planned until at least 2038), and a commitment to produce is not insurance against an allocation window.
Pattern 5 — The control requirement outgrows the reference design. Vendor FOC packages cover pumps and fans well. A servo joint needing a faster current loop, a custom observer or a high-resolution absolute encoder interface may exceed what a given device’s peripherals, compute headroom or available firmware support. That is a device-level capability question — check timers, ADC, position interface and library availability — not an automatic argument for a discrete stage.
Motor Control Engineering
The SiP-versus-discrete decision carries thermal, safety and lifecycle consequences that outlive the component choice. Closing it properly takes a measured loss and thermal budget at worst-case ambient, a safety concept that names what the component covers and what the system must supply, and a power stage matched to the real duty cycle. Promwad designs motor control hardware, firmware and control algorithms for automotive, industrial and robotics products — scalar V/f, six-step commutation, FOC and DTC across ACIM, PMSM, BLDC, DC, SRM and stepper platforms, on MCU, FPGA and embedded Linux.
Technology Platforms and Ecosystems We Work With
Platforms:
Industry body memberships:
When the Platform Decision Outranked the Component Decision
A conveyor manufacturer was buying servo drives as finished units. The drives worked. What did not work was everything around them: procurement cost tracked a third-party roadmap, and service events went back to the drive vendor instead of the OEM who owned the customer.
Promwad built a branded servo-drive platform instead, starting from an open-source motor control base rather than a clean sheet. The published outcome was roughly a 30% reduction in procurement cost, with servicing brought back under the OEM’s control — see the custom servo drive development case and our review of open-source motor control platforms.
The reason it belongs in this article is the shape of the requirement, not a claim about power-stage topology. The decisive goals were ownership of the platform and control of servicing, not a component-level optimisation.
That generalises. Wherever an OEM needs one drive platform to cover several machine variants and to stay serviceable in-house, the weighting shifts toward architectures that keep components selectable. For a single fixed-duty 12 V auxiliary node shipping in six figures a year, the weighting goes the other way and integration is the defensible default.
Solution Approach
Step 1: Build the thermal budget from the enclosure, not the reference design. Continuous and peak power, duty profile, maximum ambient inside the real housing, airflow or its absence. Then work in losses and junction temperature rather than percentages of rated power — a device may have ample margin at one duty profile and none at another with identical nominal power. Compare against the vendor’s stated operating point and its conditions. This is where SI, PI and thermal analysis belongs: before component selection.
Step 2: Write the safety concept before the shortlist. Name the ASIL or SIL target, list the safety functions, and for each one record what the component documents — shutdown paths, diagnostic coverage, independence claims, safety manual constraints — and what the system must add. On the robotics side, ISO 10218-1:2025 and ISO 10218-2:2025 incorporated most of the collaborative-application requirements that ISO/TS 15066:2016 had supplied, including power and force limiting, so new work should reference the 2025 editions directly. ISO/TS 15066 remains a published document under review, so a specification citing it is not thereby obsolete. Our guide to IEC 61508 and its sector standards covers the derivation chain; functional safety software engineering turns the concept into evidence.
Step 3: Decide how much of the power stage you need to keep adjustable. If the losses can be handled with the package’s fixed internal path plus board copper, vias and housing coupling, integration is open. If individual device selection, placement or per-switch cooling is needed, the MOSFETs belong outside the controller — which may still mean a control SoC rather than a fully discrete design.
Step 4: Test lifecycle against the programme. Match stated longevity to the production window, then ask separately what a two-quarter unavailability in year six would cost. Both answers can be acceptable; only one should be a surprise.
Real Trade-offs
Board area against thermal concentration. Integration removes most of the power-stage footprint and concentrates dissipation at one site. Where board copper and housing coupling can carry that at worst-case ambient, the trade is strongly favourable.
BOM count against substitutability. Up to 30% fewer components is real money at volume. It is also fewer independent sourcing paths. On long builds the second number eventually matters — bearing in mind that a discrete substitution still carries re-qualification effort proportional to the change.
Vendor firmware against control freedom. A validated FOC package takes a pump demonstrator from zero to spinning in days, and becomes a constraint when the application exceeds the device’s peripherals, compute headroom or library support. MCU firmware engineering is cheap to start on a reference design and expensive to retrofit around one.
Silicon against wide-bandgap. SiC can reduce losses under suitable conditions — the benefit depends on bus voltage, current, switching frequency, temperature and the specific devices compared — and junction temperatures are typically rated to 175 °C, with some devices to 200 °C. The cost is tighter gate-drive control and low-inductance layout. It is not currently embedded in integrated motor-control SiPs. GaN is arriving in the power-stage class, which integrates the switches and driver but not the controller.
Time-to-demonstrator against time-to-production. Integration compresses the drive circuit, sometimes dramatically. It does not compress motor selection, enclosure thermal design, encoder interfacing, network commissioning, parameter identification on the real load, or EMC compliance — a pattern explored in why mechatronic failures live at the seams between mechanics, electronics and firmware.
The Decision Matrix
Thresholds below are orientation points drawn from current device ranges, not architectural boundaries. Read the matrix as a weighting exercise.
| Decision input | Leans integrated SiP | Leans control SoC + external MOSFETs | Leans discrete / modular |
|---|---|---|---|
| Power and duty | Losses well inside the device’s operating point under your conditions | Power stage needs sizing per variant | Losses require individually placed and cooled devices |
| DC bus | Matches the device’s supply range (12 V class today) | Matches the controller’s range, FETs chosen to the bus | Bus exceeds available integrated devices; mains-derived or HV traction |
| Thermal strategy | Board copper, vias and housing coupling suffice | Switch choice and placement needed; controller cooling still has to be verified | Per-switch copper or bolted heatsinking required |
| Mechanical envelope | Actuator-integrated, minimal board area | Moderate area available | Area available, or power stage can be remote |
| Functional safety | Component’s documented coverage satisfies the concept with modest external circuitry | Independence achievable by separating controller and switches | Concept needs channel separation the integrated parts cannot document |
| Control requirement | Within the device’s peripherals, compute and firmware support | Controller covers the loop, FETs cover the power | Compute or interface needs exceed available co-packaged controllers |
| Lifecycle | Vendor longevity covers the window | Switches second-sourceable, controller stable | Component-level substitution needed across a long build |
| Volume and team | Six figures a year, no in-house power electronics | Platform across several duty points | Power electronics capability in place |
Work it in two passes. First exclude any architecture that fails electrical ratings or mandatory safety requirements — those are disqualifying regardless of how attractive the remaining rows look. Then compare the survivors on thermal, lifecycle and cost trade-offs.
Typical Motor Control Engineering Tasks
→ Drive Architecture and Thermal Budget Review — Loss modelling across the real duty cycle, junction temperature at worst-case ambient, and an architecture decision documented against measured constraints.
→ Power Stage and Inverter Design — Gate drive, layout and thermal management for Si, SiC and GaN switching, with EMC-aware high-speed layout and current sensing topology.
→ FOC Firmware and Commissioning — Sensored and sensorless FOC for PMSM, BLDC and ACIM, motor parameter identification, and loop auto-tuning on the real motor and load.
→ Safety Architecture for Drives — STO, SS1 and SLS concepts to IEC 61800-5-2, mapped against ISO 13849-1, IEC 61508 and ISO 26262, separating component coverage from system obligation.
→ Industrial Network Integration — EtherCAT, PROFINET, EtherNet/IP, CANopen, Modbus and IO-Link node implementation and conformance work.
You May Be Facing This If
- The thermal model was built from the reference design’s conditions rather than the enclosure’s.
- Losses and junction temperature have not been computed for the actual duty profile at maximum ambient.
- The safety concept records the component’s ASIL or SIL capability but not which functions the system must supply.
- STO or SS1 entered requirements after the drive topology was chosen.
- The platform has to cover several motor sizes but the architecture was decided on one of them.
- Longevity was checked against the datasheet and never against an allocation scenario.
- A power figure from a reference design is being used as a device limit.
Where This Becomes a System Architecture Problem
At this point the question is not which part to buy. It is how much of the design stays adjustable once the architecture is fixed, and whether the constraints most likely to move have anywhere to go.
For vehicle auxiliary nodes this sits inside ECU and embedded platform design. For battery-powered platforms, the drive and the battery management system share thermal and current budgets neither can be designed against alone. For robotics, actuator and platform engineering is where joint-level drive decisions meet machine-level safety architecture, and mechatronics design keeps electrical, thermal and mechanical budgets in one place. The broader context is power electronics design.
Promwad Micro Proof
Promwad’s published motor control work spans the range this article describes: a custom servo drive platform for conveyors built so the OEM could own procurement and service, a studio-grade direct-drive turntable combining precision motor control with embedded performance verification, and a stepper motor driver with EtherCAT integrating drive hardware, firmware and real-time networking on one node.
The control methods are matched per motor type rather than applied uniformly: FOC and DTC for ACIM and PMSM, six-step commutation and FOC for BLDC, PWM with current and speed loops for brushed DC, current chopping and angle position control for SRM, and full-step, microstepping or closed-loop control for steppers — implemented on MCU, FPGA and embedded Linux. Promwad is a member of the EtherCAT Technology Group, PI Community, OPC Foundation and CLPA.
FAQ
What is the difference between a motor-control SiP, a control SoC and a discrete power stage?
When should an EV auxiliary node use a SiP instead of a discrete design?
Can a motor-control SiP meet ISO 26262 ASIL B?
What are the thermal limits of an integrated motor-control SiP?
Why do robotics servo drives often stay discrete?
How much PCB area does integration actually save?
What voltage ceiling applies to integrated motor drivers?
Where do SiC and GaN fit?
Does an integrated SiP reduce overall development time?
Related Engineering Cases
- Design of Custom Servo Drives for Conveyors: OEM-owned servo drive hardware for conveyor platforms.
- Turnkey Design for a Studio-Grade Direct-Drive Turntable: Direct-drive motor control with embedded self-verification.
- Stepper Motor Driver with EtherCAT Support: Drive hardware and firmware with real-time industrial networking on the node.
- Delta Robot Design for Conveyors: Multi-axis motion control where joint-level decisions meet machine-level architecture.
- Converting Diesel and Petrol Trucks to Electric Motors: Vehicle electrification covering CAN/LIN integration and sensor signal emulation across converted powertrains.
- Ground Control Station and Flight Controller Design: Flight controller with external ESC command over DShot and related protocols.