[数字电源系列文章]数字电源管理——PMBus

PMBus和一个接口转换板与其产品进行通信。在多数场合中，接口转换板通过USB连接至一部主PC。基本使用模式是在总线上配置PMBus器件的所有寄存器，并将其数值存储于非易失性存储器中。这样，当系统通电或复位时，所有的器件在启动期间将从非易失性存储器来给操作存储器加载。

这种模型的基本优势在于其简单性。工具能够通过数据组织、模板和项目重用来消除PMBus的大部分复杂性。第二项优势是成本较低，因为不需要采用“额外的”器件来管理总线。

此模型的主要劣势是丧失了正常操作期间PMBus的所有功能。在异常情况下(比如：发生了故障)，所有的器件都必须自主地做出反应，但灵活性受到限制，而且缺少协调。在复位时情况同样如此。所有的器件均必须自主启动。

让我们来研究一下由此强加的某些限制条件。假设一种电源架构具有由一个IBC(中间总线控制器)运作的12轨POL(负载点)转换器。POL1存在OC(过流)故障，而且故障响应是关断电源轨。由于总线上没有用于对故障做出反应的任何主机控制器，因此其他的电源轨将继续运作，除非POL1的OC通过负载在另一个电源轨上引起了某种故障。

为了克服这些限制，许多器件都具有附加的IO引脚，这些引脚允许器件在没有PMBus的情况下进行相互通信。传统的方法是在器件之间采用漏极开路信号。通常有3个引脚：

? SYNC(同步)

? RUN(运行)

? GPIO(通用输入输出)

SYNC引脚用于在复位时建立一个公共时基。这提供了用于接通/关断事件排序的准确时间相关。RUN引脚可使所有器件利用一个外部逻辑门或器件本身实现同时复位。GPIO通常是一个故障输出和故障输入。这允许源自某个器件的故障传播至其他器件。这些引脚虽然并非PMBus规范的一部分，但为了让Configure和Deploy使用模型作为一个系统来工作，它们却是必不可少的。

监视(Monitor)和运作(Act)

最灵活的使用模型需要一个在系统操作期间处于运行状态的PMBus主机。由于能够全面使用完整的命令集，因此系统仅受限于PMBus的速度和您的想象力。

有几种用于构建PMBus主机的子模型。一个微处理器或微控制器、FPGA逻辑器件或一个嵌入在FPGA中的控制器。通常，它是某种类型的控制器，即使是内嵌于一个FPGA中。它只是更容易实现，而且更加灵活。

Alert引脚一般连接至控制器上的一个中断引脚。当存在某种故障时，微处理器(μP)通过以下方式对中断做出反应：获得故障器件的地址、通过PMBus查询相关状况、并采取措施以校正问题或使电源轨断电。

控制器也用于遥测。数据可以用来预测故障、测量功耗或调试罕见的故障。另外，控制器还将在复位时设置所有的电源轨。

该使用模型的终极价值是灵活性。不过，必需为此付出代价：开发时间/成本和更多的硬件。虽然开发成本能够借助可重用框架而略有减低，但硬件成本的额外增加却是无法避免的。

混合模型

根据我的经验，有许多工程师都在使用Configure和Deploy模型，少部分的工程师则采用Monitor和Act模型。当采用后者时，很少是以其纯粹的形式来使用。利用工具来处理大部分的配置要常见得多，借助的方法是：确保接口转换板与主机具有兼容性，并且仅将PMBus主机用于遥测、高级故障处理和最终用户通知。

另外，这种工作的划分还可提供针对策略和安全决定的某种控制。电源工程师能够通过一种工具来控制电源轨电压、启动定时和主要的故障响应。而利用针对PMBus主机所发出之容许命令的规则，嵌入式软件设计人员 的工作内容被限定为一组有助于调试的安全遥测功能和异常情况记录。

最终决定

做出有关使用模型的决策并不简单。通常，直到您设计了自己的首个数字电源架构之后才会真正了解本应当怎么做。希望通过这文章系列可使这些决策变得更加容易，而且您甚至可以在最终设计之前进行架构的原型设计(假定拥有我所提供的资源)。如果您有话题希望在我今后的文章中看到讨论，请给我们知道，我们将尽全力对其作相关的论述。