Power nets management - take 2

My recent blog post about Power nets management attracted a large number of very interesting and very informative comments. It has been heart warming, for me, to see so many people getting involved in the discussion. All these contributions have helped me appreciate how vast and intricate the domain of power management can be. It is also obviously an area of great importance to all of you, regardless of the types of design you do.

Many of these comments offer great suggestions and ideas. I would like to try and pull all this together in a coherent and organized way, that will hopefully indicate a visible and useful way forward.

I’d like to approach this by first better defining, and classifying the problems that have to be addressed in order to make power management less ‘energy consuming’ (pardon the pun) for you. Then for each problem, or class of problems, I will try to propose some possible approaches for solutions, while trying to estimate the development effort involved to implement these.

The first types of problems are elementary.

Each power network (the set of nets involved in providing power to components) should ultimately be connected to some external source of power.  Any external source of power should also deliver power somewhere. On a given power network, basic budgetary constraints should be respected (the power produced should be greater than or equal to the power consumed, the operating voltage ranges of devices connecting to a common net should match). Also, where power networks interact with signals (I refer to pull-ups and pull-downs), no spurious errors should be generated, obscuring the real errors.

Then come problems of a more complex nature.

Each power network budget should be precisely managed so as to ensure that what is supplied gets appropriately distributed (for the various parts to function properly) and ultimately collected, under all possible operating circumstances. Of concern is the amount of current provided under which voltage (for the supply side), and how it is collected and returned.

Finally, there are the more advanced issues.

Ultimately the PCB needs to be designed in a way that physically satisfies the power requirements of the parts used. To avoid repetitive work and errors, these design constraints should be automatically calculated from the schematic information. Then to verify that the result is adequate, the final PCB design should be simulated. These concern areas like power and split plane design, route management, heat management, part stress, and so on.

Simple power connection checking

For the first group of elementary problems, I think that given the means of defining a power network, its nodes and their basic characteristics, it should be relatively easy to perform elementary checks and focus the designer’s attention on potential issues.

The elementary checks that I am thinking about are:

1. There is at least one producer of power on the network.
2. The power produced on the network is greater or equal to the power consumed.
3. The voltage ranges of devices connected to the network should at least intersect.

The important question is: what would be a practical way of implementing this?

First, lets consider the way to ‘build’ a power network. A power network is merely a set of nets involved in providing power to the parts that need it.

I find part see-throughs to be a good mechanism to achieve the purpose of defining this.

I understand that the graphical representation proposed in the previous post is not adequate, and I totally see the points made - as previously depicted, they can be confusing, misleading and clutter the design space unnecessarily.

Their key purpose is to communicate that for a certain intent (here, power network definition) two nets should be considered joined. In the case of power management, they act merely as wires, and therefore should be placed on parts that do not affect the voltage in a big way.

This should be reflected by their behaviour and their graphical representation. On screen, they should be visible only in an explicit way - when the mouse hovers over an involved pin for instance, and/or according to some preference or setting. Exactly how they would look though (when and if visible at all), I have not yet determined. It certainly should be possible to exclude them from printouts and outputs. Also they will allow one-to-many relationships. It will be possible to place them either in a library or in a design context.

Then lets look at what would be required to define basic electrical characteristics on a power network. I understand that replacing the ‘Power’ pin type with two ‘Power Supply’ and ‘Power Sink’ types, while embedding electrical characteristics in pin parameters is a popular idea. However, it makes me feel uncomfortable for a number of reasons.

Firstly, it raises the issue of data updating, both in a library and design context. Given an ‘old’ Power pin, a judicious choice would have to be made when coming in the new software (was it meant to be a supply or a sink?). Given today’s real situation, it sounds like there are no easy answer. The same problem exists for backward compatibility, and data that goes back and forth between various versions of the software.

Secondly, opinions seem to diverge regarding the naming and the concepts underlying these types (Power supply/sink, Current supply/sink, Positive / Negative reference...). Some confusion might also be introduced in regards to negative power supplies.

There is also the issue of parts characteristics that vary depending on the way they are used in various designs. This goes from adjustable regulators to power delivered by generic connectors. Modifying the part pins themselves in the design is always a possibility, but this is an approach fraught with danger when it comes to rigorous data management (for instance while using Update from Libraries, or the Design Item Manager).

I think that what is required here to move forward is a more flexible system which allows the connecting pins characteristics to be declared in a simple way.

In this perspective I like the idea of ‘Tagging’ put forward by Ian. A ‘Power Tag’ is simply a connection description. It is defined by a type (Producer or Consumer), a power rating, a voltage range and a free text description. When it is placed on a pin it declares the pin electrical characteristics. It can be placed either in a library context, or in a design context.

Then, given a power network, the basic checks can easily be performed:

1. The connection types allow to check for the absence of producer or consumer.
2. All producers power [produced] can be added, and all consumer power [consumed] can be added. These two values can then be compared to check for imbalance of the power network.
3. Finally the voltage ranges of each connected pin power tag can be compared to check for a valid match.

The following images illustrate the overall approach described above. In this example, two power networks are defined: 5V0 and 3V3.

A power jack delivers 5V0 to the whole network. Directly in the schematic (since this situation is design specific)  a Power Tag describes the power characteristics of the power jack pin that is connected to the 5V0 rail.

A switch allows to turn power on an off. Since the nets +B and 5V0 are part of the same power network, and in effect at the same voltage, two see-throughs are added to link pins 1 and 3, and pins 3 and 2. A switch is always ‘transparent’, so these see-thoughs could have been added to the sch symbol itself, in a schematic library.

Then a regulator brings down the 5V0 rail to 3V3.

5V0 is delivered to an audio power amplifier. Power Tags placed on pins describe their characteristics. The power consumed value describes the worst case scenario. This can either be done in a schematic library environment, or in the schematic itself.

3V3 is delivered to a touch screen controller, which pins characteristics are described by appropriate Power Tags.

Then simple power checks can be performed on 5V0:

Producers on 5V0

Pin	Power produced (W)
J19-1	5
Total	5

Consumers on 5V0

Pin	Power Consumed (W)
U1-1	1
U26-2	1.3
U26-10	1.3
U26-15	1.3
Total	4.9

Also on this network, all voltage ranges match (J19-1 provides 5V0, while U1-1 needs 2V7~6V0, and U26-2, 10 and 15 need 4V5~5V0).

On 3V3, the same verifications can be performed:

Producers on 3V3

Pin	Power produced (W)
U1-5	480 x 10-3
Total	480 x 10-3

Consumers on 3V3

Pin	Power consumed (W)
U48-10	80 x 10-6
U48-1	750 x 10-6
U48-9	10 x 10-9
Total	830.01 x 10-6

Also on the 3V3 net, operating voltages ranges match (3.2V~3.4V, 1.2V~ 3.4V, 2.7V~3.6V, 2.7V~3.6V)

Based on this revised approach I start seeing a clear path forward to the implementation of an effective solution that addresses these elementary issues, within a few months.

It should also be possible to highlight entire power nets on demand, with some indication of their correctness.

Equally, a simple mechanism of grouping producers together, using a group index in the Power Tag, will allow us to indicate which producers will be active at the same time (and so should be summed), for redundant power systems for example. The system can take this into consideration while running the checks.

Advanced power management and analysis

I also would like to address the more complex problem of assisted power budget management.

I understand that a very useful tool would be one that, given the full electrical characteristics of involved components and the way they are connected together, could do all the maths and report whether all declared constraints are satisfied, at all time. I agree with this view.

In order to implement that in any satisfying way, the Spice simulation engine would have to be brought in, which is obviously possible.

 

In addition to the weight of adding the adequate simulation models to libraries and designs, I am not yet sure whether all possible cases can be reliably covered. Many devices’ power consumption depend on the way they actually operate in the field. To accommodate that, the Spice simulation engine would have to be equipped with means to take into account the way devices are programmed, and the way these programmed devices interact with their environment.

This sounds like a very exciting project, but one that fits in a longer term perspective. It feels to me like something worth further pondering, investigating and talking about - possibly in a future blog post!

Finally, the advanced topics of automatic rules generation and final design simulation appear equally useful if they could be effectively addressed. However, the road to their final implementation seems even more unclear.

In terms of automatic rule generation, a number of architectural problems would have to be solved in the software, like the ability to define binary rule at the schematic level for instance. Then the guidelines for the automatic rules generation would have to be clearly investigated and defined, with possibly, new rules introduced at the PCB level.

 

Also, in the world of simulation of the final result, some brand new technology would have to be either developed or acquired. A number of strategic steps would have to be taken first in order to address these aspects effectively.

This has been a rather long post, but I think the interest expressed in this subject demanded a careful analysis, and an equally detailed and honest answer. My aim to is to clearly outline a path to a useful solution that can be effectively deployed in a matter of a couple of months.