[讨论] 射频IC应用编程接口设计

随着手机内RF芯片的集成度不断增加，编程需求也在显著增加。但另一方面，手机生命周期在日益缩短。解决复杂性增加和生命周期缩短之间的矛盾的一个方法是采用“硬件”应用编程接口(API)。本文讨论开发API时应遵循的一些规则以及应避免的一些设计陷阱。
射频IC的主要工作是调制与解调发射数据并接收想要的信号。随着数字信号处理技术的出现，越来越多的射频IC架构把模拟功能和处理信号所需的数字信号处理功能块整合在一起。但是，蜂窝标准的复杂性要求作为一个整体的蜂窝芯片必须具备灵活性，特别是对射频IC而言。灵活性即意味着可编程能力。

独立射频IC的输入构造一直是串行外设接口(SPI)映射。本质上，可将该SPI映射方法看作接入射频IC的一个“开关”和“旋钮”阵列，典型情况下有若干个使能位(开关)和工作参数(旋钮)。以PLL为例，它一般至少有一个启动PLL的使能位，还可能有若干确定PLL输出频率的调节参数。

当控制IC(通常是数字基带)开始对PLL进行编程时，它必须编写参数和使能位。在基于SPI映射的接口架构中，DBB固件需了解它要编写的每一比特的地址和位置。它还必须了解SPI的构造以便能正确计算所需参数。有时，这些位彼此间会有时序方面的关联，为确保计算结果正确，必须审慎对待这种关联。

由于所需编程的比特数以千计。在某些场合，射频IC的不同子系统间存在关联，即便技术文档写得非常清楚，DBB固件开发团队也可能无法很好理解。即使当DBB固件开发团队成功地把一款射频IC整合进芯片组后，DBB固件也就因此与射频IC的特性有千丝万缕的联系。采用防御式和分层级式编程方法，仍会存留无法彻底抹去的痕迹。从商业角度看，这意味着对单一软件构造组件通过另外一个渠道进行外包几乎行不通，因为这样做就必须维护两个软件构造。此外，后续的射频IC将需要改进或升级，这样寄存器将无法严格兼容，维护起来困难重重。

在软件领域，解决这些问题的传统方法是抽象(abstraction)。抽象一般意味着对其它实体用来完成任务的一些算法进行收集。高级别的实体不关心低级别实体如何完成任务，它只要求一切都在预期的参数内运行。高级别软件使用的低级别程序集被称为应用编程接口(API)。

对抽象的期望在一定程度上把一个系统平台内的分布式IC维系在一起。增加的抽象层使得无需了解数字基带的物理逻辑细节，取而代之的是简单发布一个命令——“启动接收器”。这个命令还采用有更详细描述的语句：“启动该通道的接收器，实施AFC校正，并根据预期的信号水平在天线端设置增益”。

当然，通过API的抽象不会降低系统团队需对相关部分的参数和功能运作条件进行了解的需求。像处理任何复杂系统一样，了解各种使用环境及与最底层设计进行沟通都很关键。全面理解所需的操作将提供更完善的硬件，并有助于规避(或最起码控制)过度工程化(overengineering)。

一旦理解了相关的分布式IC使用环境，就能设计出鲁棒的API。在软件中，API由功能组成。对硬件API而言，类似的意图可能是通过接口传送至射频IC的命令。可以用一种直接明了的方式，自上而下地处理命令定义和命令参数，这将覆盖70~80%的所需功能。

射频IC的任务是发射和接收，因此，对于多模蜂窝收发器，需要用来实现以下任务的命令：使能和/或去使能GSM接收器；使能和/或去使能GSM发射器；使能和/或去使能WCDMA接收器；使能和/或去使能WCDMA发射器。

这样就可以开始搭建API的构架。每个可能的命令都提供高级别的意图。现在，每个命令都需要某类参数化处理，以使他们更加有用。每个命令的一些意图包括：想要的通道数；现有带宽(如果无法从通道数导出)；AFC校正(基于系统，如果射频IC在AFC校正中起作用)。每个命令将有其特定参数。一些命令专用参数可能包括：发射功率水平、工作时隙以及功率测试要去。

[ 本帖最后由 xtss 于 2010-3-25 17:11 编辑 ]

好，顶个先