隨著手機內RF芯片的集成度不斷增加，編程需求也在顯著增加。但另一方面，手機生命周期在日益縮短。解決復雜性增加和生命周期縮短之間的矛盾的一個方法是采用“硬件”應用編程接口(API)。本文討論開發API時應遵循的一些規則以及應避免的一些設計陷阱。

射頻IC的主要工作是調制與解調發射數據并接收想要的信號。隨著數字信號處理技術的出現，越來越多的射頻IC架構把模擬功能和處理信號所需的數字信號處理功能塊整合在一起。但是，蜂窩標準的復雜性要求作為一個整體的蜂窩芯片必須具備靈活性，特別是對射頻IC而言。靈活性即意味著可編程能力。

獨立射頻IC的輸入構造一直是串行外設接口(SPI)映射。圖(a)通常的SPI映射架構。本質上，可將該SPI映射方法看作接入射頻IC的一個“開關”和“旋鈕”陣列，典型情況下有若干個使能位(開關)和工作參數(旋鈕)。以PLL為例，它一般至少有一個啟動PLL的使能位，還可能有若干確定PLL輸出頻率的調節參數。

當控制IC(通常是數字基帶)開始對PLL進行編程時，它必須編寫參數和使能位。在基于SPI映射的接口架構中，DBB固件需了解它要編寫的每一比特的地址和位置。它還必須了解SPI的構造以便能正確計算所需參數。有時，這些位彼此間會有時序方面的關聯，為確保計算結果正確，必須審慎對待這種關聯。

由于所需編程的比特數以千計。在某些場合，射頻IC的不同子系統間存在關聯，即便技術文檔寫得非常清楚，DBB固件開發團隊也可能無法很好理解。即使當DBB固件開發團隊成功地把一款射頻IC整合進芯片組后，DBB固件也就因此與射頻IC的特性有千絲萬縷的聯系。采用防御式和分層級式編程方法，仍會存留無法徹底抹去的痕跡。從商業角度看，這意味著對單一軟件構造組件通過另外一個渠道進行外包幾乎行不通，因為這樣做就必須維護兩個軟件構造。此外，后續的射頻IC將需要改進或升級，這樣寄存器將無法嚴格兼容，維護起來困難重重。

在軟件領域，解決這些問題的傳統方法是抽象(abstraction)。抽象一般意味著對其它實體用來完成任務的一些算法進行收集。高級別的實體不關心低級別實體如何完成任務，它只要求一切都在預期的參數內運行。高級別軟件使用的低級別程序集被稱為應用編程接口(API)。

對抽象的期望在一定程度上把一個系統平臺內的分布式IC維系在一起。增加的抽象層使得無需了解數字基帶的物理邏輯細節，取而代之的是簡單發布一個命令――“啟動接收器”。這個命令還采用有更詳細描述的語句：“啟動該通道的接收器，實施AFC校正，并根據預期的信號水平在天線端設置增益(如圖(b)所示)”。