数字电源排序

电源排序是数字电源架构的一个关键部分。在这我们来看看几种设计排序的方法及其结果。特别地，我们将了解一下设计选择在设计过程的后期对灵活性所产生的影响。

电源转换的构件

让我们来看一下自己的电源构件和工具，并了解我们会给自身带来何种类型的麻烦。为简单起见，我们假定拥有一个通用的电源构件(UPB)以及所有常见的“麻烦制造者”(例如：FPGA和微控制器、以及逻辑器件等)。我们的UPB具有一个简单的接口：

图1：电源构件。

我们简单的电源转换器具有单个VIN/VOUT、一个PMBus接口、一个输入信号(CONTROL)、以及两个输出信号(POWER GOOD和FAULT/)。

CONTROL

CONTROL信号负责输出的接通和关断。其为高电平有效，并具有一个内部上拉电阻器。

POWER GOOD

POWER GOOD信号在输出通电时为高电平，而且它处于有效范围之中。

FAULT/

FAULT/信号为低电平有效，开路漏极，并在电源构件具有某种故障时被置为有效。如果存在某种故障，则ALERT/被置为有效，并且可以通过PMBus读取故障信息。不是所有的电源转换器都将具有一个POWER GOOD和一个FAULT/，我们不需要两者兼备。几乎在每种场合中，FAULT/皆可作为POWER GOOD的“替身”。

设计方案一

现在我们来设计某种方案，这样就可以将之拆解并设计另一种方案，从而一次比一次做得更好。

假设我们有一个系统，此系统具有一个中间总线控制器(IBC)和以下的电源轨：48V、19V、5.0V、3.3V、1.2V、0.8V。

我们决定把这些电源轨构造为一种层级体系。不过，我们需要一种用于上电的不同控制结构。

图2：简单的电源结构。[!--empirenews.page--]

对于实际的设计，不要担心电源层级体系或逻辑是否正确。要紧的是这种结构“类型”所产生的影响。我们来研究一下其优缺点。

从好的方面来说，不管是在原理上还是对于实现，它都是很简单的。添加LED指示器或者利用一个FPGA或微处理器的GPIO来读取电源良好信息将非常容易。如果出现故障情况，POWER GOOD将让系统知道某个电源轨发生了故障。

从坏的方面来说，假如存在某种故障，而且倘若系统必须关断所有的电源，那么就必须按照与其上电时相同的顺序把它们逐个关断(别无选择)。这意味着，位于最下游的电源轨将由于失去电源而断电，而不是通过其控制引脚来实现断电。

由于没有定时控制，因此将不得不增添额外的电路以在电源轨之间安置延迟。如果在电源轨之间添加一个延迟，则该延迟将仅适用于上电，因为一个馈电电源轨上的电源将在断电时丢失，因而将在POWER GOOD信号可以使其关断之前关断其所依赖的电源轨。

对于这种结构“类型”，如果您出现任何错误，那么将必需进行PCB的重新布局，而且在等待的过程中，您将被迫修改设计中的导线(别无选择)，或者去“享受”漫长的休息时间。

设计方案二

如果我们将逻辑电路集中管理，就能做得更好。一个可编程器件(例如：FPGA或微处理器)能够管理所有的逻辑电路。

通过把所有的逻辑线路均排布至GPIO，控制器即可实现针对排序顺序(接通和关断)以及定时操作的全面控制。其可在希望改变Verilog或C代码时随时变更。我已经标示了控制器上的PMBus(但并未绘出所有的接线)，而利用PMBus，控制器现在还能控制电平和故障行为特性。

图3：采用控制器的电源结构。

就优点而言，该设计具有灵活性，而且您不会陷入焦头烂额的困境。假如您在控制结构中出错，无需重新布局即可加以修复。

就缺点来说，您不得不改变Verilog或C，而且有可能需对固件重新实施测试和鉴定。另外，这种设计还必需进行大量的布线。每个POL需要5根控制线，而且它们单独地排布至控制器。假设我们有一个20轨系统，由于PMBus的原因，将需要42个GPIO引脚。

所以，这种设计虽然具有灵活性，但需要很多的GPIO并占用大量的PCB面积资源。

设计方案三

当与PMBus及智能数字电源POL组合时，我们可以采用开路漏极控制的特性来简化控制器。

所有的CONTROL引脚连接在一起，而所有的FAULT/引脚连接在一起。这意味着一个20轨系统只需要5根接线，从而使IO引脚的数目减少了8倍。

图4：简化的控制器。[!--empirenews.page--]

让我们来看看这是怎样奏效的。CONTROL引脚为高电平有效。其受控于GPIO0(这被设定为“开路漏极”)。由于CONTROL引脚为开路漏极，这意味着POL也可将其拉至低电平。

当POL复位时，它将把CONTROL引脚拉至低电平，直到其准备好响应一个外部信号为止。这意味着倘若控制器速度过快，则不会有任何一个POL接通(直到它们全部正确复位为止)，而且系统何时上电取决于最慢的POL复位。如果控制器速度较慢，则其在释放CONTROL线时负责控制上电。

您可能对排序感到困惑不解。我们失去对它的控制了吗?不，没有，因为PMBus具有一个TON_DELAY命令，而且其数值一般存储在POL的非易失性存储器(NVM)中。它可由控制器来设定，也可以采用一种外部工具存储于NVM中。

FAULT/引脚亦为开路漏极并受控于GPIO1，而且它们既是输入也是输出。这意味着当出现任何电源轨故障时，所有的电源轨都将在FAULT引脚被拉至低电平时得到通知。而且，当FAULT/被拉至低电平时，ALERT/被置为有效。于是，控制器获知存在某种故障。众人皆知，这款设计的关键之处便在于此。

现在，关于故障处理您可以有几种选项。PMBus能够利用一个报警响应地址(ARA)来响应ALERT/，这可获得所有具某种故障之POL的地址，并随后查询每个POL以了解故障信息。接着，其可采用一个决策树并按照需要以任何顺序关断电源轨。或者，它也可以立即关断全部的电源轨，而让PMBus TOFF_DELAY来管理定时。

许多POL具有增强型故障管理功能，并可直接响应故障(请记住，FAULT/也是一个输入)。典型响应为：

• 重试

• 立即关断

• 斜坡关断

当POL具备这些高级特性时，Verilog或C代码的工作负荷就会大大减轻，因为POL可利用一种外部工具(通过PMBus和外部接口及软件)来编程。此外，当采用FAULT/引脚时，针对故障的响应速度要比处理ALERT/的响应速度快得多。

设计方案三的权衡折衷

如果有了增强型的POL，即可实施权衡取舍。假如故障逻辑对于共用的FAULT/线来说过于复杂，则只需增添一个控制器。如果故障逻辑很简单，那么可以采用一种工具来配置故障行为特性，且不必使用控制器。或者，也可以使用一个控制器来实现远端采样和其他功能，但采用FAULT/引脚来执行故障处理。而且，假如发现其不能处置所有的故障情况，您始终能够增添用于故障处理的代码并加以变更。对于CONTROL引脚采取了相似的折衷方案。您还可以采用PMBus取而代之。在该场合中，CONTROL引脚仍将推迟接通，直到所有的POL均已完成复位为止。

当CONTROL和FAULT引脚共用、且有一个用于PMBus的控制器时，可实现最大的灵活性。利用这种设计，在PCB制作完成之后可具有全面的灵活性。

电源良好(Power Good)

可能您没有注意到，我并未使用POWER GOOD。某个电源轨什么时候处于良好状态，关于这一点您在接通另一个电源轨之前无需知晓。如果全部电源轨由TON_DELAY控制，而一个未能及时处于就绪状态，则将发生某种故障。PMBus规定了TON_MAX_FAULT_LIMIT，这限定了某一电源轨必须在多长的时间里斜坡上升并进入容差范围之内。倘若某个电源轨到这个时候尚未处在规格指标之内，则将出现故障，从而阻止其他电源轨接通。

设计原理是：没有消息就是好消息。如果系统需要知道什么时候全部电源轨都已上电，则只需把一个简单的定时器设定至由所有TON_DELAY规定的最长时间即可。或者，控制器也可执行最后一个POL之状态的PMBus查询。

在某些器件中，可以把FAULT/引脚重新配置为POWER GOOD引脚。这使得您能够在真正需要的时候拥有POWER GOOD，但将失去故障信息共享(fault sharing)引脚。于是，您可能希望有一个控制器来响应ALERT/。或者，在较为简单的系统中，ALERT/有可能夺取CONTROL引脚的功能，并在出现某种故障时关断所有的电源轨。

在实际当中，POWER GOOD通常并不是必不可少的。不过，假如您真的需要，通常可采取对FAULT/进行重新配置的方法。毕竟，总会有一些特殊的情况。也许始终存在适合该“通用适配器套件”(Universal Adapter Kit)的空间。

我们来回顾一下

这里我们做一番简要的概述，以方便那些直接跳到结尾的读者快速了解本文的要义：

我把第一种设计所采用的原理称之为“事件排序”。POWER GOOD引脚连接至下一个POL的CONTROL引脚。但其不具备可配置性以及对故障行为特性的控制能力。第二种设计采用了一个控制器并将所有的排序置于其命令之中，但它采用了大量的GPIO，您因而被迫让控制器去完成所有的任务。第三种设计采用开路漏极引脚以共享CONTROL和FAULT/，并提供了一个任选的控制器。这种设计具有许多灵活性，GPIO引脚数目较少且布线简单。当主要的折衷是有关控制器的决策时，这是最受欢迎的设计方法。关于此项折衷，在以后的文章中将做更多的阐述。设计方案一和设计方案二并无过错，只要您理解并能适应其限制条件即可。但是我们都知道，在系统鉴定过程中一旦突发意外问题，那么游戏规则就会突然改变。即使您觉得自己并不需要设计方案三，它仍不失为一项极为出色的保险策略。我所能说的是：假如我是电源工程师，而且有一支规模庞大的工程师团队依赖于我的设计，那我肯定不想在出现差错时陷入困境。我想，如果我延误了某款产品的发布，他们是不会太高兴的。