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

我打算发表一些有关以实际结构和集成数字电源管理产品为题的相关文章。我会涉及到以下题目：PMBus，使用模型，电源排序，故障处理，工具，嵌入式软件，结构，器件类型，系统调试。

有很多博客和文章都在简要中吹棒数字电源的优点。看过我文章的读者都知道，我非常务实。在这里更是如此。如果我提到软件，那就是代码。如果我提到硬件，那就是原理图。我的文章如果没有达到您的预期，请您提出来。

对于有些基础的人，我从简要介绍PMBus开始，然后是提及工程师们使用的主要应用模型。随后，会越来越深入，直到所介绍的实例足以帮助你们开始自己的设计。

PMBus

大部分人认为PMBus是具有一些额外功能的I²C总线，通常并不完全清楚这些额外的功能是什么。实际上，很多设计人员把PMBus当做I²C，没有充分发挥其优点。PMBus是SMBus的扩展，而后者是I²C的扩展。因此，让我们从I²C开始。

I²C (Inter-IC)

I²C不过是具有一对信号的串行总线：CLOCK、DATA。它是双向的，而且是多主机。I²C最早出现在1982年，先后有4个调整版本。1992年，正式发布了1.0版。1998年发布2.0版，这一版本非常明确的宣布：I²C总线已成为事实上的世界标准，现在已经在1000多种不同的IC上实现，并授权给50多家公司。但是，目前很多应用需要速度更高的总线，电压更低的供电电源。而I²C总线规范的更新版满足了这些要求。

后来在2007年，3.0版定义了1Mbit/s时钟速率。2012年，时钟被提高到5Mbit/s。

注释：如果您不熟悉更高比特率的内容，那么，您要小心这一假设。更高的比特率并不意味着低延时。为能够在慢速器件总线上实现更高的比特率，在进入高速传送模式之前，必须要在400Kbit/s的较低比特率进行授权。

SMBus(系统管理总线)

SMBus 1.1版于1998年制定完成并发布。1.1节说明了它与I²C的关系：系统管理总线(SMBus)是一种两线式接口，与简单的系统和电源管理相关的芯片可通过该接口与系统的其余部分进行通信。SMBus是基于I²C的工作原理。

SMBus为系统及电源管理关联的任务提供了一种控制总线。采用SMBus的系统在其自身与器件之间传递消息，而不是触发专用控制线。取消专用控制线可减少引脚数目。接收消息确保了未来的可扩展性。

1.3节阐明了最重要的一点：SMBCLK和SMBDATA引脚类似于I²C总线上的时钟和数据引脚。SMBus的电特性不同于I²C的电特性。

虽然相似，但并不相同。大致说来，不要过于想当然。应仔细阅读SMBus规范。例如，电平就是不同的。

PMBus增添了一些旨在使其更加坚固的特性，比如：

• 数据包错误检查(PEC)

• 警告(Alert)

• 超时(Timeout)

PEC用于保证数据完整性，Alert负责在设备要求维修时中断主机控制器，而Timeout则可避免总线挂接。它们在多设备系统中均非常重要。

SMBus 2.0版于2000年发布，并增加了更多的特性：

• 主机通知协议

• 地址解析协议

PMBus(电源系统管理协议)

PMBus 1.0版于2005年发布，1.2版则于2008年发布，因此这是一个相当新的协议。PMBus与SMBus具有相似性，事实上PMBus采用了部分SMBus规范作为其基础。PMBus的传输层即为具有扩展和例外的SMBus 1.1。

扩展：

• 块写入–块读出进程调用

• 主机通知协议

• 群组命令协议

• 扩展命令

• 总线速度：400kHz(采用定时修改)

• 电气驱动电平

例外：

• 块写入/读出(高达255数据字节)

现在，我们给它添加一种用于设定电压、电流、定时和故障管理的命令语言。最后，在该命令语言之外还有应用协议。而让我们感到疑惑不解的是：工程师们为什么要纠缠于怎样使用PMBus！

复杂性

SMBus 1.1标准的篇幅达39页。PMBus 1.2则为125页。而且，制造商们除此之外还添加了他们自己的特殊寄存器和功能性(配有100多页的相关规范)。那么，如何应对所有这些复杂性呢？基本上是借助工具和重用。当然，还包括相关的规范，其可通过System Management Interface Forum获得。

使用模型

我将提出两种重要的使用模型，虽然可能还有其他的使用模型，不过此二者是我发现得到大量运用的两种主要模型：

1. 配置(Configure)和部署(Deploy)

2. 监视(Monitor)和运作(Act)

最重要的PMBus命令集之一用于存储和恢复操作存储器和非易失性存储器之间的设定值。当与用于改变操作存储器(行为特性)的命令相组合时，其可支持Configure和Deploy使用模型。

配置(Configure)和部署(Deploy)

大多数PMBus产品制造商都拥有一种GUI工具，该工具可通过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主机所发出之容许命令的规则，嵌入式软件设计人员