基于FMC手机的低功耗设计方案

　　图2：融合手机第一代平台架构。（来源：恩智浦半导体）

　　第二代融合手机

　　由于越来越多的用户使用蓝牙耳机，第二代融合手机一般都集成了蓝牙（BT）功能。这类手机集成了三个射频系统，并在它们之间进行协调：由于采用协同工作滤波器，GSM与BT以及GSM与WLAN可以一起工作。BT/WLAN共用同一频段，彼此之间干扰严重，因此需要复杂的射频接入协调，特别是BT和WLANIC之间进行紧密协调。

　　图3：融合手机第二代平台（来源：恩智浦半导体）

　　除此以外，第三个系统（BT）在空闲（扫描）和通话（即在使用耳机模式）时也需要额外功耗。因此BT子系统本身与所在的整个系统架构都需要具备很好的能效。

　　WLAN专用PMU，进一步改善系统能耗。采用专用于WLAN和/或BT平台的PMU，可以避免因LDO（线性稳压器）造成的损耗，从而达到进一步改善能耗的目标。

　　功耗需求的变化

　　功耗需求在过去的两年里发生了相当大的变化。用户刚开始还能接受一些解释：手机内置WLAN，这会损耗一些电量，待机时间只有GSM的一半。不久以后，要求WLAN待机时间达到数天则成为主要目标。但这依然没有满足消费者的期望：电池即便在支持相同的待机时间基础上还要能够通话一段时间（如3个小时）。此目标运营商们保持了一段时间。

　　第一批消费者的反馈表明融合手机必须具备与普通GSM手机相同的性能。消费者不希望因采用FMC技术而带来任何明显的差异，因此，运营商不但不会宣传，甚至会对用户进行隐藏该项技术。“普通”GSM手机的另一个市场推动力是Razr的成功，以及随之不断增长的对超薄手机的需求。现在，相同功能和性能的GSM手机（也包括FMC手机）一般都采用650mAh电池，而不是1000mAh，因此所有手机元件（包括WLAN）需要节约30%的能耗。图5是功耗要求的典型演化图，随后将讨论实现这一目标的解决方案。

　　图4：融合手机第三代平台。（来源：恩智浦半导体公司）

　　关键系统设计

　　整体设计

　　作为独立的子系统，WLAN子系统需要拥有自己的时钟、电压控制、省电模式管理，以及必要时激活主机的能力。必须避免在空闲时间内两个系统并行工作：如果可以使用首选系统（WLAN），则另一个系统（GSM）需要进入睡眠状态。为了取得良好的关键性能和用户体验，某些偏差也可以接受（例如，在通话期间）。使处理器之间的通信最小化。WLAN只有在收到相关数据时才激活主机。RSSI（电平）测量应在WLAN子系统内局部进行—只有测量值超出给定极限才激活主机。

　　图5：UMA 手机功耗的演变过程。

　　协议分层及例外

　　嵌入软件通常按照OSI模型进行分层：物理层在专门的硬件/DSP/CPU上运行（尤其是BT、WLAN、GSM、UMTS）；低功耗在硬件和软件中都采用“内置设计”（即通过时钟/电压等级、省电模式等）；较高层将在功耗更高的主CPU（或应用CPU）上运行；通常涉及到不同组织、路线图、团队、软件语言、OS、工具和限制等。

　　作为通用规则系统架构应按照时间域布置软件层：GSM中，每一帧的处理应在DSP上完成而不是主CPU（以前情况并非如此，通常项目预算也不允许完全重新设计），不过协议工作应在主CPU上完成。

　　以下例外情况如果可以实现，则将大大降低待机功耗：

　　GSM中：协议每0.5秒检查用户收到的信息是否为呼叫，这项工作可以转交DSP，使主CPU有更长的睡眠时间。

　　WLAN中：每0.1秒—0.5秒进行一次RSSI和其它测量，但只有当动态下载极限超出上、下值并将产生动作时，才应激活主处理器。

　　惰性范式

　　一般情况下，所有算法设计时都考虑最差状态下的最佳性能。如果有足够的可用电源，这种方法不会产生任何问题，但通常情况下这一要求会过高，从而需要根据实际情况进行调整。

　　－每0.5秒查看邻近小区可以产生良好的切换性能，而在空闲状态下此动作可以被简化。

　　－使用外部电源工作时（充电器、USB电缆），可以选择最高性能的算法，而使用电池时则减少此类操作。

　　－只要用户进行操作（如按键）就应激活高性能算法，但在一段时间内没有任何操作，则应使用电池优化算法。

　　－软件只应做必需的事情（在限制功耗状态下），只在必要时刷新缓存，而不是采用自动定时刷新的方式。

　　－手机要考虑到环境的变化，如检测“全天同一位置”与“不断移动”的情况，以释放网络扫描等请求。

　　-高级节能措施还需要考虑电池状态的变化：如果电池电量下降，则移动切换速度、TX功率、屏幕刷新等性能也需要进一步降低。

　　－系统范式需要全局接口以及应用于整个系统的单一设计，如“使用电池”与“使用电源”状态或活动指示等。所有算法都需要这些信息。

　　关键软件设计

　　替换“Do…While”循环

　　嵌入软件一般具有很多以并行逻辑运行的RTK任务。多数情况下，软件需要等待某个条件为真，如“AP已关联”、“IP地址已分配”和“呼叫已建立”等。最初采用一种简单的方案（经常用于“C”语言），即在一个任务中使用“Do…while”命令，并用循环轮询来获得较低优先级任务的结果（如IP协议栈）。

　　此时，CPU保持运行直至条件成立，这将导致高功耗。实际例子：等待显示器完成刷新。

　　较好的方案是启动RTK定时器，然后进入一段睡眠时间，过后再次检索条件。这种方法原理上仍是一种“轮询”，但减少了对功耗的影响，并可以采用不同的睡眠间隔度，动态地适应不同的性能需求。

　　更好的方案是采用RTK消息与中断，当最终达到条件时激活主机。这样能够最大程度地降低功耗，不过中断是一种稀有资源，而系统架构必须在设计时就考虑最高效功耗。不幸的是，功耗问题一般在产品生产后期才被发现，因此需要进行重新设计，但很少有人会重新设计。

　　定时器管理是关键

　　嵌入软件经常需要从几毫秒到数天的定时范围，特别是硬件处理、软件轮询，或由标准给定（IP、电信等）。定时器到时需要激活CPU并运行RTK/OS程序。退出省电模式后需要一段时间来达到系统稳定，而返回省电模式也需要一些时间来准备下一次的正确激活。CPU激活一般非常快（在微秒范围），但主时钟仍需运行，这样只节省了少量功耗。全系统的睡眠（包括主时钟）可能需要5至20毫秒的激活时间，但只有这种方法才能提供最大的节能效果。

　　应尽可能避免出现定时器频繁过期情况。给定900毫秒的定时器可以通过900x1毫秒、90x10毫秒、9x100毫秒的tick（时钟计时单元）来实现，这样做对功耗有着全然不同的影响。操作系统应使用最大tick长度。这意味着为获得最大节能效果，必须尽可能放松对定时器精度的要求，例如不采用900毫秒（此时操作系统tick的时间间隔为100毫秒），实际应用中“1秒”可能已经足够。手机拥有与实际空中接口物理层相关的系统tick。使用这些tick而不是人工的毫秒/秒单位，就可以减少激活的次数。GSM每帧4.615毫秒，使用这个时长为一个“tick”成为自然的选择。语音采用多个20毫秒做为时间间隔，需要不同的tick。WLAN信标基于100毫秒的自然tick间隔。

　　功耗问题将永远存在

　　手机行业属于快速变化的行业，每年都会在新款手机上增添很多新功能，而用户期望的使用时间却与上一代手机一致，甚至更长。即使在更大屏幕尺寸、更大画面尺寸、更多可存储音乐，以及更多的接入网方式（用户甚至经常看不到）的情况下，用户对电池使用时间的预期依然不变。鉴于提高电池容量