Bob White谈论PMBus规范更新

今天，我们与PMBus电源管理协议的发起人BobWhite，他是PMBus规范工作组的长期主席以及PMBus和SMBus规范编辑。Bob是PMBus规范的主要作者，并参加PMBus规范工作组。他是一位著名的演讲者和作家，经常在诸如IEEEAppliedPowerElectronicsConference（IEEEAPEC）之类的会议上发表论文和研讨会。以下是EEWorld的JeffShepard对Bob的采访。

鲍勃·怀特（BobWhite）是PMBus®电源管理协议的创始人，也是咨询和设计服务公司EmbeddedPowerLabs的总裁兼首席工程师。

JS：鲍勃，自PMBus发布更新以来已经有一段时间了。您能告诉我们PMBus小组一直在做什么吗？

BW：杰夫，正如您所说，PMBus小组已经安静了一段时间，但我们一直很忙。

我们一直在努力更新现有规范，同时期待新一代PMBus。对于当前版本，SMBus规范的3.2版和PMBus规范的1.4版处于最后一轮的审阅，评论和编辑。

JS：SMBus规范的下一版本中有哪些更新？

BW：与3.1版相比，SMBus规范的3.2版所做的更改大部分是对文本和图形的小错误的更正。进行了一些澄清，3.2中没有对SMBus功能进行真正的更改。

JS：SMBus规范使用诸如“主”和“从”之类的术语来指代SMBus设备。这些术语被批评为不敏感，其他总线规范也在改变这些术语。PMBus工作组是否正在考虑进行任何更改？

BW：杰夫，工作组适应更改这些术语的需要。我们正在仔细观察并注意I²C总线的决定，因为SMBus是I²C总线的适应和发展。目前看来，在SMBus和PMBus规范的下一版本中，“控制器”将代替“主”，而“目标”将代替“从”。

JS：那很有趣。SMIF是否会返回并使用术语“控制器”和“目标”来更新旧版本？

BW：我们已经讨论过了，但是目前还没有计划更新旧版本的规范。

JS：谢谢您对SMBus的更新介绍。PMBus的下一步是什么？

BW：PMBus电源管理协议于2004年9月在达内尔电源论坛上引入。PMBus规范的修订版1.0于2005年3月发布。自PMBus规范从修订版1.0变为修订版1.3.1以来的十六年中。我认为原始的PMBus规范已经非常出色，这证明了原始的PMBus规范工作组的成员的努力。

但是时代和技术在变化。在最初的工作组中，我们非常担心电源转换器中数字电路的成本。我们非常关心如何在当时的8位微控制器中有效地实现PMBus协议。如今，数字技术的成本几乎可以忽略不计，常见的数字通信总线速度已经从数百千赫兹提高到了千兆赫兹，并且像基于ARM内核的32位处理器无处不在。

为了使PMBus向前发展，PMBus工作组正在采取两步走方法。第一步是用修订版1.4封装当前的规范。目标是版本1.4是这一代的最后一个版本。我们预计永远不会有1.5。

1.4将进行一些次要的功能更新和一些重要的说明，尤其是在PAGE_PLUS功能方面。我们曾希望去年秋天发布1.4版，但其口号是“做到正确”，而不是匆忙发布。似乎每次我们都准备进行最终审查时，就好像是每次准备。有人发现了另一个小错别字，图形错误或需要澄清的要点。正如我们所说的，工作组非常希望能够在第一季度末之前将修订版1.4进行最终审核和投票。

JS：如果修订版1.4是当前PMBus规范的终结之路，那么下一步将是什么？

BW：工作组概述了PMBus2.0的构想，但目前，它仍在进行中。

计划中的一项关键更改是AVSBus2.0将作为规范发布。虽然它将与PMBus规范保持联系，但可以根据自己的需要自由地进行开发。例如，现有的AVSBus是一种将一个控制器与一个目标设备链接在一起的点对点协议。AVSBus2.0将具有支持多个目标设备的控制器。AVSBus用户社区经常请求此功能。

对于PMBus2.0，原始PMBus工作组的愿景之一是PMBus命令语言将适用于在SMBus以外的其他物理接口上运行。虽然已经完成了一些早期工作，以便通过PS-485接口运行PMBus，但是该工作目前停滞中。

PMBus2.0的愿景是拥有在不同总线和接口上运行的通用命令语言。除了今天的基于SMBus的PMBus，工作组还积极研究通过标准串行总线（RS-232，RS-485），SPI，CAN总线，以太网甚至USB等接口运行PMBus。我们已经讨论了通过蓝牙等无线协议的PMBus，但是目前，通过无线接口的PMBus将是一个未来的项目。

JS：在如此众多的总线和接口上运行PMBus是否有特殊的挑战？

BW：需要注意两个挑战。首先是数据格式。尽管所有数字数据都以字节为单位进行通信，但是本地数据宽度从8位到32位再到64位还有将来的128位或更多存在很大变化。问题是，我们如何编写一种命令语言，使其能够轻松适应将命令和数据传递到各种本机数据位宽的问题。

第二个挑战是SMBus和以太网等接口之间通信的基本区别。像SMBus这样的接口就是我所说的基于“事务”的接口。控制器开始与目标设备的通信，发送命令和数据，也许接收数据，然后关闭通信。一切，命令和数据交换都在一个事务中进行。当事务完成时，控制器知道目标已接收到命令并且数据传输已完成。按照当今的标准（每秒兆位），此类接口的带宽（比特率）较小，但是通信中没有延迟（延迟）。

其他接口，例如CAN总线和以太网，都是基于消息的。在这种情况下，控制器将命令和所有相关数据组合在一起，创建一个消息包，然后将该消息启动到总线上。控制器不知道预期目标何时或是否接收到消息。如果成功接收到该消息，则目标可以发送一条返回消息，以确认已接收到原始消息，确认命令已正确执行，并返回任何请求的数据。同样，目标不知道控制器何时或是否接收到消息。这里的带宽可能很高-每秒千兆字节-但延迟未知。

构建PMBus2.0以使其与数据宽度和消息传输（事务与消息）的这些变化良好地配合将需要格外小心。

JS：EEWorld读者应该了解PMBus工作组的其他活动吗？

BW：最初的PMBus工作组的另一个愿景是，主要的OEM将根据他们的需求创建PMBus规范的子集。那从来没有真正发生过，但是需要适合特定应用的PMBus规范子集。

这些子集称为应用程序配置文件。现在正在努力开发一种应用配置文件，该配置文件定义了用于非服务器AC-DC前端电源的PMBus规范的标准子集，例如工业或通用计算应用程序中使用的电源。由于委员会成员忙于日常工作，这项工作进展缓慢。重要的是要记住，所有PMBus工作组和规范活动都是由志愿者执行的。他们可以承诺加入PMBus的时间因雇主的需要而异。

PMBus工作组也早已认识到需要一种标准文件格式，该标准文件格式可用于在生产环境中对PMBus设备进行编程。这个想法是要有一个程序员，它可以是任何东西，从运行Windows的PC到运行嵌入式Linux的RaspberryPi，再到连接需要编程的PMBus设备的专用微控制器。这些PMBus器件可以是PCB或前端电源上的负载点转换器。然后将配置这些PMBus设备所需的PMBus命令放入标准格式文件中，程序员可以读取该文件。程序负责解释文件，然后将命令发送到要编程的设备。编程文件还可以包括一些命令，这些命令将回读已编程的信息以确认设备正确编程。

至于编程文件，工作组讨论了JSON之类的格式和XML之类的标记语言。当前的想法是，该文件将采用YAML文件格式。

随着这项工作的进展，其目的有所发展。除了仅由独立程序员使用之外，还需要使此文件可被板载控制器（例如服务器中的基板管理控制器（BMC））使用，以编程或更新其系统中的PMBus设备。该工作组正在研究Redfish和OpenBMC等组织的工作，以确保PMBus文件格式在这些环境中可用。

JS：听起来PMBus小组正在进行很多工作。如果有人对志愿服务和贡献感兴趣，他们如何参与其中？

BW：除了通常参与PMBus规范的开发外，需要帮助的特定领域包括为各种接口（如CAN总线，USB和以太网）定义PMBus2.0协议。需要帮助的另一个领域是标准PMBus编程文件格式的开发，包括那些具有生产编程经验的人或那些熟悉OpenBMC和Redfish的人，以确保在这些环境中可以使用标准PMBus编程文件格式。

关于BobWhite

Bob在设计电子设备的电源，dc-dc转换器和电源系统方面拥有30多年的经验。目前，Bob是咨询和设计服务公司EmbeddedPowerLabs的总裁兼首席工程师。他在产品开发，技术开发，系统和应用工程以及技术营销方面担任管理和个人贡献者职位。他之前曾在诸如EmersonElectric，ArtesynTechnologies，AT＆TPowerSystems/BellLaboratories和DigitalEquipmentCorporation等公司。

Bob拥有麻省理工学院的电子工程学士学位（1980）和伍斯特理工学院的电子工程硕士学位（1991）。他目前正在攻读博士学位。在罗伯特·埃里克森（RobertErickson）教授的指导下，在科罗拉多大学-博尔德分校就读。他是IEEE的院士。