Streamlining Power Supply Design to Optimize SWaP-C and Accelerate TTM
2024. 3. 25
Power supply solutions also tend to be some of the most expensive components in the system bill-of-materials (BOM).
Get the whole Whitepaper now
Introduction
There are many compelling reasons to optimize the design process—particularly for the power supply subsystem, which is often viewed as a necessary inconvenience rather than a direct contributor to high-value system features. Power supply solutions are also among the most expensive components in the system bill of materials (BOM). These factors, combined with the confidence that comes from reusing a qualified design block or a commercially available power module, strongly motivate the adoption of a leverage/reuse strategy across successive projects.
A review of the typical power solution design process
To fully understand the motivations behind leveraging or reusing power supply solutions, it's useful to briefly examine the typical design process and pinpoint the gaps and opportunities that drive these strategies. Whether you're a direct power stakeholder or a recipient of power supply design services, if the generalized process outlined below aligns with your experience, you're likely not alone in that perspective.
Figure 1 outlines the typical high-level steps a team might follow to progress from concept to establishing a system power budget and defining physical or environmental constraints. While not an “official” process – there’s a bit of humor involved – it still reflects a lot of real-world truth.
The “magic” segment refers to the unrealistic demands that stem from overinflated power budgets, which can call for efficiencies, densities, or transient responses that are either impractical for the product class or simply unattainable, even with state-of-the-art (SOTA) technology.
Figure 1 outlines the typical high-level steps a team might follow to progress from concept to establishing a system power budget and defining physical or environmental constraints. While not an “official” process – there’s a bit of humor involved – it still reflects a lot of real-world truth.
The “magic” segment refers to the unrealistic demands that stem from overinflated power budgets, which can call for efficiencies, densities, or transient responses that are either impractical for the product class or simply unattainable, even with state-of-the-art (SOTA) technology.
Rx The “Official” Power Supply Design Process
- Step 1: All system stakeholders (typically minus the Power stakeholder) get together and architect a system.
- Step 2: Determine system power budget by summing maxima of all major loads in the system.
- Step 3: Confirm feasibility with the Mechanical/Thermal stakeholder.
- Step 4: Provide power budget, volumetric constraints, and project timeline to Power Stakeholder.
- Step 5: Magic?!? (i.e. — forget physics and reality)
Fig. 1: The “Official” Power Supply Design Process, courtesy of PowerRox
A key takeaway is that while power stakeholders are expected to meet these outputs, they are often excluded from the process that generates the inputs. Given that power engineering is a specialized discipline requiring a multidisciplinary background—typically built through years of hands-on experience – it’s surprising how rarely these stakeholders are consulted early on. This is especially problematic given that power subsystems are often the primary gatekeepers to optimizing system size, weight, power, and cost (SWaP-C). Since no electronics function without power, performance and reliability must also be added to that list. To make matters worse, the project timeline is usually built around an idealized, flawless development cycle – often shortened by 10% to improve time-to-market (TTM) over the previous generation – layering even more pressure on top of these already unrealistic expectations.
Now comes the negotiating process. Engineers are trained to be problem solvers, so when faced with a list of challenging problems, the kneejerk response is to start digging into solutions (i.e. – Is there an existing part that can meet this power density and footprint? Should airflow go from front-to-back or back-to-front to meet the system thermal envelope? And so on...). Even this initial step is an opportunity to pause and examine the system budget—and how it came to be.
For instance, how often are all loads (especially the larger ones) drawing their maximum currents simultaneously? Many subsystems are intentionally designed to operate in antiphase with others (e.g. – the classic examples of compute vs. memory power demands or sleep/wake/transmit operating cycles), so it's rare that the sum of maxima – often taken from datasheets already reflecting unrealistic maximums with added safety margins – makes sense as an aggregated power budget. Consider every touch point in that power budget from inception to finalization. Each stakeholder is likely to add their own margins to satisfy their specific guidance, and these layers accumulate quickly. Those added layers of “fat” can cost significant money and engineering resources when designing for scenarios that are truly unrealistic, even under extreme corner-case modeling.
Another key point in the fight against overinflated system power budgets is recognizing where the biggest opportunities for optimization lie. Start by identifying the largest, most demanding loads in the system, and consult with the critical stakeholder(s) who best understand what those loads actually require in terms of power. Whenever possible, gather real characterization data. This process often opens the door to implementing intelligent power management (IPM) techniques, such as aggregating lower-voltage power rails, load sharing or shedding, and short-term power allocation.
IPM is defined as a “combination of hardware and software that optimizes the distribution and use of electrical power in computer systems and data centers” [1]. While the term originated in the context of data centers, its applicability is broad, as IPM is more of a design mindset than a specific solution. For example, shifting the power subsystem architecture mindset from “always on” to “always available” can produce paradigm-shifting results in the final system design. Achieving this will require extensive collaboration with both internal team members and external vendors.
In other words, it is often far simpler, faster, and more cost-effective to invest the effort into reducing the system power budget to a realistic summary of worst-case, maximum power loading (from each individual power supply’s perspective), rather than pouring that effort into trying to bend physics – or available components – to meet unrealistic expectations. Given the constant pressures around time and cost reduction, this approach allows for a much smoother negotiation process among team stakeholders and helps establish a pragmatic balance between time, cost, and quality. These inevitable tradeoffs are tightly linked, no matter how much we wish they weren’t, as illustrated in the figure below. For example, a product may be optimized for any two of time, cost, or quality – but rarely all three at once.
Now comes the negotiating process. Engineers are trained to be problem solvers, so when faced with a list of challenging problems, the kneejerk response is to start digging into solutions (i.e. – Is there an existing part that can meet this power density and footprint? Should airflow go from front-to-back or back-to-front to meet the system thermal envelope? And so on...). Even this initial step is an opportunity to pause and examine the system budget—and how it came to be.
For instance, how often are all loads (especially the larger ones) drawing their maximum currents simultaneously? Many subsystems are intentionally designed to operate in antiphase with others (e.g. – the classic examples of compute vs. memory power demands or sleep/wake/transmit operating cycles), so it's rare that the sum of maxima – often taken from datasheets already reflecting unrealistic maximums with added safety margins – makes sense as an aggregated power budget. Consider every touch point in that power budget from inception to finalization. Each stakeholder is likely to add their own margins to satisfy their specific guidance, and these layers accumulate quickly. Those added layers of “fat” can cost significant money and engineering resources when designing for scenarios that are truly unrealistic, even under extreme corner-case modeling.
Another key point in the fight against overinflated system power budgets is recognizing where the biggest opportunities for optimization lie. Start by identifying the largest, most demanding loads in the system, and consult with the critical stakeholder(s) who best understand what those loads actually require in terms of power. Whenever possible, gather real characterization data. This process often opens the door to implementing intelligent power management (IPM) techniques, such as aggregating lower-voltage power rails, load sharing or shedding, and short-term power allocation.
IPM is defined as a “combination of hardware and software that optimizes the distribution and use of electrical power in computer systems and data centers” [1]. While the term originated in the context of data centers, its applicability is broad, as IPM is more of a design mindset than a specific solution. For example, shifting the power subsystem architecture mindset from “always on” to “always available” can produce paradigm-shifting results in the final system design. Achieving this will require extensive collaboration with both internal team members and external vendors.
In other words, it is often far simpler, faster, and more cost-effective to invest the effort into reducing the system power budget to a realistic summary of worst-case, maximum power loading (from each individual power supply’s perspective), rather than pouring that effort into trying to bend physics – or available components – to meet unrealistic expectations. Given the constant pressures around time and cost reduction, this approach allows for a much smoother negotiation process among team stakeholders and helps establish a pragmatic balance between time, cost, and quality. These inevitable tradeoffs are tightly linked, no matter how much we wish they weren’t, as illustrated in the figure below. For example, a product may be optimized for any two of time, cost, or quality – but rarely all three at once.
Fig. 2: The Time/Cost/Quality Triangle
Articulating the difference between leverage and reuse is important when communicating with program managers or external vendors, as each term can imply something very different – even though they are often used interchangeably. Miscommunication here can lead to negative program or solution impacts. Leverage refers to taking an existing solution and tweaking minor aspects (e.g. – passive component values, signal/logic/comparator thresholds, cosmetics, form factors, etc.) to optimize it for a similar, though not identical, use case. In this context, semi-custom is a commonly used synonym for leverage.
This distinction becomes particularly important when speaking with a component vendor about a “fully custom” design (i.e. – built from the ground up) versus a “semi-custom” design, which typically involves modifications to a commercial off-the-shelf (COTS) solution. The differences between the two can have significant implications in terms of quoted price (both component and non-recurring engineering, or NRE) and lead time.
Direct reuse refers to taking an existing design and copying it exactly. In effect, this is comparable to purchasing COTS (commercial off-the-shelf) components, though there can be some gray areas – since certain fixed designs are intentionally created with flexibility in mind. For example, reusing power bricks with a wide input voltage range or programmable output can support various applications. It’s also common to leverage a part family, particularly when dealing with power modules designed for standardized footprints. This allows for optimizing specific module characteristics – such as input/output voltage range, power density, current handling, pinout, and filtering – to better suit the application.
This distinction becomes particularly important when speaking with a component vendor about a “fully custom” design (i.e. – built from the ground up) versus a “semi-custom” design, which typically involves modifications to a commercial off-the-shelf (COTS) solution. The differences between the two can have significant implications in terms of quoted price (both component and non-recurring engineering, or NRE) and lead time.
Direct reuse refers to taking an existing design and copying it exactly. In effect, this is comparable to purchasing COTS (commercial off-the-shelf) components, though there can be some gray areas – since certain fixed designs are intentionally created with flexibility in mind. For example, reusing power bricks with a wide input voltage range or programmable output can support various applications. It’s also common to leverage a part family, particularly when dealing with power modules designed for standardized footprints. This allows for optimizing specific module characteristics – such as input/output voltage range, power density, current handling, pinout, and filtering – to better suit the application.
In general, common criteria for determining whether a case qualifies as leverage or reuse come down to a test of three key characteristics: form, fit, and function (i.e. – aesthetics, mechanical/thermal compatibility, and electrical/communicative performance). This is another area where careful negotiation and detailed discussions with team partners and solution providers pay big dividends, as some organizations have very strict definitions for adhering to form/fit/function.
For example, taking the exact same power supply and changing its ENABLE or POWER ON signal logic from positive to negative (high-level turn-on vs. low-level turn-on) may seem too minor to shift from direct reuse to heavy leverage – but that single change might trigger a full new round of qualification testing, just like a new product (e.g. – new part numbers to manage and all that comes with it), thereby placing it in the leverage category.
Even more seemingly trivial is changing a word, statement, or value on a printed label of a power brick. But if that label relates to safety – or if it affects part number formatting or unique identification stored in EEPROM – then new regulatory compliance testing may be required and/or manufacturing processes adjusted. This would break the form/fit/function criteria. Having survived the process of negotiating the system power budget, one can now confidently focus on proposing solutions to make that budget a reality. Given the time and cost pressures, the initial effort will typically focus on known-good solutions or subcircuits (a.k.a. – macros), which is where leverage and even direct reuse become highly valuable. It’s important to ensure that what’s being leveraged or reused are solid, proven solutions – not just recycled out of operational pressure (with one exception noted below).
This highlights the importance of allocating time and resources for the things we often claim “we don’t have time/resources to address.” Blind reuse also carries forward any bugs or shortcomings from the original design. In fact, some organizations with strict adherence to form/fit/function requirements may even demand that a second-source component intentionally mimic a known bug or defect to maintain backward compatibility during multisourcing (NOTE: Multisourcing is a topic worthy of its own deep dive and should be carefully evaluated for its pros and cons before implementation – though that is outside the scope of this white paper).
Neglecting iterative improvements from one product generation to the next can significantly impact operational efficiency. On the other hand, reusing a proven, trusted design with well-understood performance characteristics can greatly accelerate development (i.e. – the platform design approach). There are many well-established, reliable power vendors available to support this strategy – especially when using COTS power modules.
For example, taking the exact same power supply and changing its ENABLE or POWER ON signal logic from positive to negative (high-level turn-on vs. low-level turn-on) may seem too minor to shift from direct reuse to heavy leverage – but that single change might trigger a full new round of qualification testing, just like a new product (e.g. – new part numbers to manage and all that comes with it), thereby placing it in the leverage category.
Even more seemingly trivial is changing a word, statement, or value on a printed label of a power brick. But if that label relates to safety – or if it affects part number formatting or unique identification stored in EEPROM – then new regulatory compliance testing may be required and/or manufacturing processes adjusted. This would break the form/fit/function criteria. Having survived the process of negotiating the system power budget, one can now confidently focus on proposing solutions to make that budget a reality. Given the time and cost pressures, the initial effort will typically focus on known-good solutions or subcircuits (a.k.a. – macros), which is where leverage and even direct reuse become highly valuable. It’s important to ensure that what’s being leveraged or reused are solid, proven solutions – not just recycled out of operational pressure (with one exception noted below).
This highlights the importance of allocating time and resources for the things we often claim “we don’t have time/resources to address.” Blind reuse also carries forward any bugs or shortcomings from the original design. In fact, some organizations with strict adherence to form/fit/function requirements may even demand that a second-source component intentionally mimic a known bug or defect to maintain backward compatibility during multisourcing (NOTE: Multisourcing is a topic worthy of its own deep dive and should be carefully evaluated for its pros and cons before implementation – though that is outside the scope of this white paper).
Neglecting iterative improvements from one product generation to the next can significantly impact operational efficiency. On the other hand, reusing a proven, trusted design with well-understood performance characteristics can greatly accelerate development (i.e. – the platform design approach). There are many well-established, reliable power vendors available to support this strategy – especially when using COTS power modules.
If a design team is working on multiple system developments concurrently and/or in rapid succession, they are likely to develop a go-to toolbox of power solutions, sub-blocks, or product families suited to a range of standard application scenarios. This toolbox often includes pre-built, pre-qualified, and pre-tested power modules – whether developed in-house or sourced from a power supply vendor.
Naturally, this strategy supports optimization of all SWaP-C factors, as previously discussed, but its primary value lies in mitigating risk – particularly in critical, high-reliability, or high-volume deployments. For example, while an isolated power supply for a SiC driver can be constructed using a transformer driver, transformer, rectifier, and LDO, a ready-made DC/DC module (such as RECOM’s RxxP1503D with asymmetric output voltages optimized for gate driver performance) not only accelerates the R&D phase but also consolidates multiple components into one BOM item. This significantly reduces the chance of an error that could damage an expensive SiC transistor.
Naturally, this strategy supports optimization of all SWaP-C factors, as previously discussed, but its primary value lies in mitigating risk – particularly in critical, high-reliability, or high-volume deployments. For example, while an isolated power supply for a SiC driver can be constructed using a transformer driver, transformer, rectifier, and LDO, a ready-made DC/DC module (such as RECOM’s RxxP1503D with asymmetric output voltages optimized for gate driver performance) not only accelerates the R&D phase but also consolidates multiple components into one BOM item. This significantly reduces the chance of an error that could damage an expensive SiC transistor.
Streamlining the System Design Process
Know your team stakeholders
This extends well beyond the core engineering team directly involved in system development. It should also include program managers (PMs), supply chain owners, manufacturing personnel, and even the software/firmware (SW/FW) designers. Though it may seem counterintuitive, some of the most important stakeholders to engage early on are the marketing and sales teams – along with anyone who has direct contact with customers or end users. It’s far better to negotiate compromises and make informed decisions early, rather than have them dictated later in a top-down manner without input from power solution stakeholders – as highlighted at the beginning of this white paper. Avoid the “if we build it, they will come” mindset. If market requirements and customer potential are not clearly understood before initiating a new project, the risk of product failure increases significantly.
Know your technology
Don’t wait until design kickoff to start thinking about conducting an industry survey – either to get a sense of the latest advancements or to refresh outdated information used in previous projects. Inviting vendors to provide technology or roadmap updates can be an excellent way to quickly gain an overview and tap into vendor resources to consolidate proposed solutions. This may even give you a head start on competitive analysis. Leveraging the support of motivated external partners to survey the vast industry landscape can save significant time and effort – and reduce the risk of missing out on state-of-the-art (SOTA) technologies. Most vendors will welcome the opportunity (and maybe even throw in lunch) for early engagement in potential developments.
NOTE: Always consider the source of any information and approach it critically. This underscores the importance of developing strong, working relationships with key vendors and service providers. In high-stakes development projects, a “customer is always right” mindset doesn’t always lead to the best engineering outcomes. A collaborative relationship that shares some level of risk often increases the chances of success for everyone involved.
NOTE: Always consider the source of any information and approach it critically. This underscores the importance of developing strong, working relationships with key vendors and service providers. In high-stakes development projects, a “customer is always right” mindset doesn’t always lead to the best engineering outcomes. A collaborative relationship that shares some level of risk often increases the chances of success for everyone involved.
Plan ahead of, during, and after project completion
Plan ahead of, during, and after project completion! Take time to review a “design playbook” or collection of learnings (a.k.a. – best practices, golden nuggets, etc.) before diving too deep into project or product definition. Often, the most recent issues from the last project are the ones that get overlooked because the team was under pressure to get the product out the door. Don’t hesitate to schedule team meetings multiple times throughout the project – ideally once per major phase or milestone – especially for reviews related to Design for Anything (DFx), safety/compliance (including powerline and electromagnetic interference or EMI compatibility), and user experience. The last point ...
Want to read the whole Whitepaper?
용도
