Michael Jones, Linear Technology
Many digital power products use industry-standard PMBus to implement system architecture to manage and control multiple power rail structures. However, many people do not know how to apply PMBus to solve practical problems.
I intend to publish some related articles on the actual structure and integrated digital power management products. I will cover the following topics: PMBus, usage models, power sequencing, troubleshooting, tools, embedded software, architecture, device types, system debugging.
There are many blogs and articles that blow the advantages of digital power supplies in brief. Readers who have read my article know that I am very practical. This is especially true here. If I mention software, that's code. If I mention hardware, it is a schematic. If my article does not meet your expectations, please ask it.
For some basic people, I started with a brief introduction to PMBus and then mentioned the main application models used by engineers. Then, it will go deeper and deeper until the examples introduced are enough to help you start your own design.
PMBus
Most people think that PMBus is an I2C bus with some extra features, and it's often not entirely clear what these extra features are. In fact, many designers regard PMBus as I2C and do not fully exploit their advantages. PMBus is an extension of SMBus, which is an extension of I2C. So let's start with I2C.
I2C (Inter-IC)
I2C is nothing more than a serial bus with a pair of signals: CLOCK, DATA. It is bidirectional and it is multi-master. I2C first appeared in 1982, and there have been four adjusted versions. In 1992, the 1.0 version was officially released. The 2.0 version was released in 1998. This version is very clear that the I2C bus has become the de facto world standard and is now implemented on more than 1,000 different ICs and is licensed to more than 50 companies. However, many applications currently require higher speed buses and lower voltage power supplies. The updated version of the I2C bus specification meets these requirements.
Later in 2007, version 3.0 defined a 1Mbit/s clock rate. In 2012, the clock was raised to 5 Mbit/s.
Note: If you are not familiar with higher bitrate content, you should be careful about this assumption. A higher bit rate does not mean low latency. To be able to achieve higher bit rates on the slow device bus, it is necessary to authorize at a lower bit rate of 400 Kbit/s before entering the high speed transfer mode.
SMBus (System Management Bus)
SMBus version 1.1 was developed and released in 1998. Section 1.1 explains its relationship with I2C: The System Management Bus (SMBus) is a two-wire interface through which chips associated with simple system and power management can communicate with the rest of the system. SMBus is based on the working principle of I2C.
SMBus provides a control bus for system and power management related tasks. Systems that use SMBus deliver messages between themselves and the device rather than triggering dedicated control lines. Removing the dedicated control line reduces the pin count. Receiving messages ensures future scalability.
Section 1.3 illustrates the most important point: The SMBCLK and SMBDATA pins are similar to the clock and data pins on the I2C bus. The electrical characteristics of SMBus are different from those of I2C.
Although similar, they are not the same. In general, don't take it for granted. The SMBus specification should be carefully read. For example, the level is different.
PMBus adds some features designed to make it more robust, such as:
• Packet Error Check (PEC)
• Alert
• Timeout
PEC is used to ensure data integrity, Alert is responsible for interrupting the host controller when the device requires maintenance, and Timeout to avoid bus hookup. They are very important in multi-equipment systems.
SMBus 2.0 was released in 2000 and adds more features:
• Host notification protocol
• Address Resolution Protocol
PMBus (Power System Management Protocol)
PMBus 1.0 was released in 2005 and version 1.2 was released in 2008, so this is a fairly new agreement. PMBus is similar to SMBus. In fact, PMBus uses some SMBus specifications as its basis. The PMBus transport layer is SMBus 1.1 with extensions and exceptions.
Extensions:
• Block Write - Block Read Process Call
• Host notification protocol
• Group command protocol
• Extended commands
• Bus speed: 400kHz (with timing modification)
• Electric drive level
exception:
• Block write/read (up to 255 data bytes)
Now we add a command language for voltage, current, timing and fault management. Finally, there are application protocols outside the command language. And what puzzles us is: Why do engineers have to struggle with how to use PMBus!
Complexity
The SMBus 1.1 standard has 39 pages. PMBus 1.2 is 125 pages. Moreover, manufacturers have added their own special registers and functionality (with more than 100 pages of relevant specifications). So how do you deal with all these complexities? Basically with the help of tools and reuse. Of course, related specifications are also included, which are available through the System Management Interface Forum.
Use model
I will propose two important usage models, although there may be other usage models, but these two are the two main models I have found to be widely used:
1. Configure and Deploy
2. Monitor and Operation (Act)
One of the most important PMBus command sets is used to store and restore set values ​​between the operating memory and the nonvolatile memory. When combined with commands for changing operational memory (behavior characteristics), it supports the Configure and Deploy usage models.
Configure and Deploy
Most PMBus product manufacturers have a GUI tool that communicates with their products through PMBus and an interface converter board. In most cases, the interface converter board is connected to a host PC via USB. The basic usage pattern is to configure all registers of the PMBus device on the bus and store their values ​​in non-volatile memory. In this way, when the system is powered up or reset, all devices will load the operating memory from non-volatile memory during startup.
The basic advantage of this model is its simplicity. Tools can be reused to eliminate most of the PMBus complexity through data organization, templates, and project reuse. The second advantage is lower cost because there is no need to use "extra" devices to manage the bus.
The main disadvantage of this model is the loss of all PMBus functionality during normal operation. In an abnormal situation (eg, a fault has occurred), all devices must react autonomously, but flexibility is limited and there is a lack of coordination. The same is true at reset. All devices must start autonomously.
Let us examine some of the restrictions imposed thereby. Suppose a power architecture has a 12-rail POL (point of load) converter that is operated by an IBC (Intermediate Bus Controller). There is an OC (overcurrent) fault in POL1 and the fault response is to turn off the power rail. Because there is no host controller on the bus to react to the fault, the other rails will continue to operate unless the POL1 OC causes some fault on the other rail through the load.
To overcome these limitations, many devices have additional IO pins that allow the devices to communicate with each other without PMBus. The traditional method is to use open-drain signals between devices. There are usually 3 pins:
• SYNC (synchronous)
• RUN (run)
• GPIO (General Purpose Input Output)
The SYNC pin is used to establish a common time base on reset. This provides an accurate time correlation for the sequencing of the on/off events. The RUN pin allows all devices to use a single external logic gate or the device itself for simultaneous reset. GPIO is usually a fault output and fault input. This allows faults originating from one device to propagate to other devices. Although these pins are not part of the PMBus specification, they are essential for Configure and Deploy to use the model as a system.
Monitor and Operation (Act)
The most flexible usage model requires a PMBus host that is running during system operation. Due to the full use of the complete command set, the system is only limited by the speed and your imagination of the PMBus.
There are several sub-models for building PMBus hosts. A microprocessor or microcontroller, FPGA logic device, or a controller embedded in the FPGA. Typically, it is a type of controller, even embedded in an FPGA. It's just easier to implement and more flexible.
The Alert pin is normally connected to an interrupt pin on the controller. When there is a fault, the microprocessor (μP) reacts to an interrupt by obtaining the address of the faulty device, querying the PMBus for related conditions, and taking actions to correct the problem or power down the power rail.
The controller is also used for telemetry. Data can be used to predict faults, measure power consumption, or debug rare faults. In addition, the controller will also set all the power rails on reset.
The ultimate value of this usage model is flexibility. However, the price must be paid for: development time/cost and more hardware. Although development costs can be slightly reduced with reusable frameworks, an additional increase in hardware costs cannot be avoided.
Mixed model
In my experience, many engineers use the Configure and Deploy models, while a few engineers use the Monitor and Act models. When the latter is used, it is rarely used in its pure form. It is much more common to use tools to handle most of the configurations by ensuring that the interface conversion board is compatible with the host and that only the PMBus host is used for telemetry, advanced troubleshooting, and end-user notification.
In addition, this division of work can also provide some control over policy and security decisions. Power engineers can use a tool to control the rail voltage, startup timing, and major fault response. With the rules for permissive commands issued by the PMBus host, the embedded software designer's job was limited to a set of secure telemetry functions and exception records that helped debug.
final decision
Making decisions about using the model is not simple. Often, you don’t really understand what you should do until you design your own first digital power architecture. Hopefully this set of articles will make these decisions easier, and you can even prototype the architecture before the final design (assuming you have the resources I have provided). If you have topics that you would like to see discussed in my future articles, please let us know and we will do our best to discuss them.
The Transformer is a device which changes the alternating current Du voltage by using the principle of Bai electromagnetic induction. The main components are primary coil, secondary coil and iron Dao core (magnetic core). The main functions are: voltage conversion, current conversion, impedance transformation, isolation, voltage stabilization (magnetic saturation transformer), etc.
Transformer
Transformer,Powell Switchgear Manual,High Voltage Transformer,Earthing Truck Switchgear
Shandong Shunkai electrical equipment co., LTD. , https://www.chinasdsk.com