在Ericsson、Nokia等電信龍頭的大力鼓吹下，藍芽技術已經成為PC開發商、行動電話製造商及許多消費性產品製造商一致看好的熱門技術，這也促使許多新款的藍芽應用模組和晶片組的不斷推出。雖然，系統整合和晶片設計廠商紛紛投入藍芽技術的應用開發，但是，要完全實現藍芽技術，使藍芽應用產品真正商品化，還有很多問題有待克服，這包括以SoC設計的矽智權（IP）模組的開發與整合、不同廠牌的互通性、單價和成本。這些問題需要以系統化的方法來解決，目前國外廠商們的作法是以相同的平台進行藍芽技術的設計與整合（platform-based designs），並且，使用不同的模擬技術來加速各種整合工作，這能有效解決藍芽產品商品化的問題。

傳統方法的缺失

在SoC的時代裡，要將藍芽技術推向成功，系統設計商和晶片設計商之間必須要有效地完成矽智權的交換及交易。藉由採用相同平台的設計和更高層次的抽象（higher levels of abstraction）技術，可以解決藍芽矽智權交換的問題。不過，國外這種技術合作開發的新觀念，是否能被國內廠商們所接受而普及，仍然有待觀察。

在傳統的藍芽產品開發過程中，晶片設計商提供不同的內核（core）能力、系統整合商使用不同的開發工具，這使得不同廠牌的藍芽產品不能互通。這個問題可能會妨礙整個晶片的設計過程，進而影響最終系統的開發。值得慶幸的是，現在已經有了新的設計模型和抽象方法可以解決這個問題，並使系統整合廠商能夠更快地將藍芽產品上市。

《圖一 藍芽通訊協定堆疊》

藍芽通訊協定技術

藍芽技術是一種短距離的無線傳輸技術，其目的是取代傳統的實體電纜。藍芽工作在2.4GHz頻段，它應用了跳頻擴譜（FHSS）技術，每發送或接收完一個數據封包後，就在不同通道之間跳轉，從而避免信號干擾。

圖一所示為藍芽通訊協定堆疊。藍芽無線電模組，即藍芽規範所定義的最底層，定義了工作在2.4GHz頻段的藍芽收發器的需求。藉由在79個間隔為1MHz的頻率之間跳轉完成擴頻，典型的起始頻率為2.403GHz。就最終產品（end product）而言，這些RF元件或RF模組可能是系統整合商的核心技術，設計時需要類比模擬工具來模擬連續時間之效應。

在藍芽通訊協定的實體層（PHY）上，基頻信號是在RF載波上調變的資訊，它負責實體通道、鏈接、糾錯、為降低直流偏壓（DC bias）的亂碼處理（data whitening/scrambler）、跳頻選擇以及藍芽安全等，如圖二。實現這項功能所需要的演算法(可由專業的協力開發商授權使用)通常採用數據流（data flow/bit stream flow）描述來進行建模（modeling）和模擬。簡述基頻數據流的建立過程如下：

* 封包頭（Header）: 產生封包頭-> 添加封包頭除錯碼（HEC）->亂碼處理 （scrambling/ whitening）-> 前向除錯編碼（FEC encoding）->與經亂碼處理過的數據內容（scrambled payload）組合。

* 數據內容（Payload）: 插入數據內容-> [添加數據內容除錯碼（CRC）] -> [加密（Encryption）] ->亂碼處理-> [前向除錯編碼] -> 插入封包頭

* 上述中括弧[ ]內的步驟，是依據封包或鏈路（link）類型的不同來決定是否要執行。

* 在封包頭和數據內容裡都需要經過亂碼處理，而且是先處理封包頭，再處理數據內容，位元是以串列方式進入亂碼處理器，亂碼處理器只需在開始時，啟動一次就可以。

在藍芽技術中，鏈路的建立、驗証、設定及其它通訊協定都是經由鏈路管理器（Link Manager；LM）處理，鏈路管理器是藉由鏈接管理通訊協定（LMP）與其它藍芽裝置的鏈路管理器進行通訊。鏈路管理器利用底層的鏈路控制器（LC）所支援的服務內容，使它成為服務供應者的角色。邏輯鏈路控制與適配通訊協定（L2CAP）位於基頻通訊協定之上，它允許更高層的通訊協定和應用程式能接收和發送最大為64KB的數據封包。另一個通訊協定RFCOMM能在L2CAP之上模擬串列埠（serial port）。

使用規範描述語言（Specification Description Language；SDL）工具，來開發藍芽通訊協定軟體的協力廠商會授權給系統整合商使用。而藍芽晶片設計商可使用有限狀態機(Finite State Machine；FSM)來描述基頻的控制邏輯。這些模組功能必須與應用軟體密切組合，才能完整地實現最終產品的核心功能。

藍芽通訊協定中還融合了一個服務發現通訊協定（SDP），該通訊協定能使應用程式了解附近的藍芽設備中可提供哪些服務項目，它還可以更詳細地了解這些可使用的服務項目的特性。另一個重要的通訊協定是主控制器介面（HCI），該介面為L2CACP提供了一個與基頻控制器和鏈路管理器溝通的命令介面，並可擷取硬體狀態暫存器和控制暫存器之內容。

《圖二 藍芽基頻內部架構》

需要三種不同的模擬技術

儘管藍芽通訊協定堆疊比較小，但系統和晶片設計團隊仍然要處理三種不同的建模和模擬技術。為了將這些建模和模擬技術和越來越複雜的藍芽SoC設計結合在一起，設計團隊需要採用更先進的設計方法。這些方法包括：在相同平台中設計和整合、採用更高層次的抽象，以及不同模擬技術的異質整合。下面首先介紹於相同平台上設計的優勢。

如今，隨著設計的複雜度增加與上市時間的壓力增大，從無到有地完成每一個設計工作是不可能的。由於設計模組中的每個改變都需要進行完整的重新驗証，因此，縱然是可合成（synthesizable）的設計模組也很難重複使用，因為連它都可能被修改。於是，國外的系統和SoC設計團隊現在採用「設計模組再使用（design block reuse）」技術，對「再使用模組（reused block）」不做修改。該方法參考自印刷電路板（PCB）的設計。這就產生了基於相同平台的設計技術，這種技術在產品開發過程中，一直維持平台的基本架構不變，這就好像硬體設計團隊不會一直更換他們的主機板一樣。

基於相同平台的設計方法的主要問題之一就是難以實現差異化。由於使用通用的SoC平台，系統和晶片設計商可能開發出與競爭對手幾乎一樣的藍芽產品。在相同的平台上設計時，產品的差異性可以藉由兩種方法來實現：即藉由軟體實現產品差異化和使用標準介面從平台程式庫（platform library）中增加硬體元件來實現差異化設計。這類似目前的PC硬體設計商大都在微軟的視窗作業系統中，開發出各自的硬體產品一樣。

基於平台的設計方法改變了各個設計團隊在設計供應鏈中的互動方式，甚至可以讓不同類型的公司互動起來。在半導體整合平台中，最著名的有TI公司針對無線電應用提供的開放式多媒體應用平台（Open Multimedia Application Platform；OMAP）、飛利浦半導體公司的Nexperia平台和Tality的藍芽平台。各公司可以從標準的平台系統開始，藉由使用軟體或更換平台架構中的模組來增加其獨特的功能，以實現差異化的設計。利用系統級（system-level）工具，系統設計商和晶片設計商之間的互動就可以提早進行，這是在暫存器傳輸層（RTL）和嵌入軟體採購簽約之前。如果在這互動期間，規格有所異動，必須重新更改工程設計（Engineer Change；EC）時，因為晶片和嵌入軟體的詳細架構都尚未決定，因此並不會造成嚴重的困擾。

在這個過程中，抽象的作用越來越重要，半導體公司再也不能僅僅提供平台的實現模型，系統整合商現在還需要抽象的系統平台模型，俾使在早期就能對系統功能之取捨做評估和對其它設計因素做考量。此外，半導體商（silicon provider）還向軟體開發商提供一個平台規範以及相對應的應用程式介面（API），以便軟體開發商設定和修改平台。

在一個典型的相同平台的設計方法中，設計團隊可能至少會採用三種不同的模擬類型。無線信號可能會在模擬類比連續時間數據的環境中進行分析；數據流模擬器也會用來分析藍芽的基頻信號；最後，離散事件（discrete event）模擬器將會用來評估圖一中所示的藍芽通訊協定。這牽涉到三種不同的時序模擬，不同於以往的是：以前所使用的不同技術之間的簡單型協同模擬（co-simulation）已經不實用了，因為上述所提的三種不同的模擬器之時間基準（time base）是完全不同的，而且要同時模擬整個系統，必須花費很多時間或記憶體數量。

綜合上所述，可以整理出一個結果：在藍芽設計中會有三個挑戰：

A. 無線電模組和基頻解碼器之間的相互作用；

B. 基頻模組與通訊協定之間，以控制主導功能的介面；

C. 軟硬體之間的組合以及系統開發商（system house）與SoC供應商之間的互動。

《圖三 Cadence的SPW採用了K模型》

類比抽象

無線接收器RF前端中的混合信號射頻電路一般位於天線和DSP之間。在這個電路中，包含能產生噪音的非線性類比元件，如低噪音放大器（LNA）、混頻器和振盪器等。RF模組從類比RF載波上萃取出數位信號數據，類比元件的噪音使基頻信號產生失真。典型的設計困難在於根據類比電路架構，對一個特定的通道接收器組合進行誤碼率（BER）估計。若仍然使用具有數據流模擬功能的Spice或與之同類型的類比數據協同模擬器，由於其模擬時間太長，實務上並不可行。

不過，K模型（Kalman filter model）能解決這個難題。K模型在無線接收器中有著廣泛的應用，它是類比電路的離散時間行為模型，它能顯示出由RF接收器引起的線性和非線性的基頻信號失真，並可應用於以C++設計數據流演算法的系統級模擬上。大多數通道的變化範圍很大，在做數據流模擬時，K模型萃取了類比電路的特性，其所產出的行為模型代表了速度與準確度的實用折衷。K模型與以C++設計的模型一起執行時，它們並不需要使用類比模擬器。這個完美的結合，在連續時間類比模擬和DSP中使用的數據流模擬之間，提供了一個高效率的介面。因此，RF的類比特性可以藉由K模型將之數位化，此數位化模型可以成為基頻的RF模擬信號，基頻設計商從此就可以擺脫RF類比電路的噩夢了。

圖三顯示了如何使用「抽象」來實現這一結合。K模型從模擬電晶體模式開始，到模擬非線性RF電路。它以輸入信號的幾個確定的振幅值，求得頻率傳遞函數，藉以決定K模型的特性。為了使K模型能準確地代表類比效應，設計團隊應該在類比域（頻域）作一次瞬態分析，並將此分析結果與從數據流模擬器中所得到的數據流模擬結果進行比較。描述特徵和比對驗証之後，K模型就可代表接收器，應用在以C++設計的數據流模擬模型中。基頻信號解碼後，送到控制系統模組，這個模組決定進一步的處理需求，如語音處理、視頻處理或簡單的數據儲存。控制模型可以用離散事件計算模型進行有效模擬，在模擬過程中，只要有任何一個有效輸入，就執行這些模型。

相比之下，數據流模型只有當全部輸入都有效時才執行。由於模組的執行次序可以預先確定，因此數據流模擬要比離散事件模擬快很多。圖四是一個藍芽產品的模擬系統架構圖。圖中顯示了一個發送器和接收器路徑，兩個基頻控制器與來自數據流模擬器的輸入模組連接。LC和HCI是以C和C++設計的模型，驅動此模擬系統的測試平台（testbench）也是以C和C++設計。根據「開放式模型介面標準（OMI，IEEE 1499）」，在EDA廠商提供的幾種系統級設計模組整合工具之間，存在著數據流與控制塊的相互鏈接。

在輸入到OMI封裝模型時，一定要產生必要的邏輯，以便在離散事件環境下執行輸入的數據流模型。為了實現這一目的，要自動插入了一個觸發器模組，以便在模擬中，若發生所有輸入皆為有效時，能即刻將觸發器模組啟動。這使得通訊協定軟體在軟硬體聯合設計環境下，進行整合和評估成為可能。

圖四也描述了藍芽系統的功能整合，其中通訊協定模組和基頻控制器實現電子設備的藍芽功能。功能整合的目的是評估不同系統模組之間的互相作用情形。在圖四中，數據流基頻模組執行某些編解碼任務，功能模擬與通訊協定模組被設計為純C/C++模型，使用離散事件模擬可以事先發現控制與數據流方面的難題（deadlock）和鏈接問題。設計團隊應該注意的是，基頻控制器與通訊協定模組之間的通道並不是使用K模型。儘管理論上是可行的，但是考慮到總體模擬所需的冗長時間以及過長的通訊協定序列，這種模型將會很慢，因此，實務上並不可行。

《圖四 藍芽產品的模擬系統》

取捨（trade-off）分析

在SoC設計中，硬體和軟體的關係越來越緊密，尤其是以相同平台來設計時更是如此。其實際產品的差異性，通常都是使用軟體來實現的。現在，國外已經有硬體/軟體聯合驗証等標準方法，可以用來解決硬體/軟體介面之間的驗証細節問題。然而，在作為架構的取捨分析工具時，其適用性受到了指令集模擬（Instruction Set Simulation；ISS）之模擬速度的限制，指令集模擬是使用慢速的硬體描述語言（slow HDL）或C++模組一起模擬的，這將導致同樣慢的模擬速度。而且，所有的模組必須在這些工具能夠使用之前就要完成。這兩個因素使得藉由這些技術來鏈接半導體設計和系統設計成為不可行。解決這個問題的一種方法是：有效率地使用「抽象」技巧。軟體和硬體的實現都可利用許多種不同的描述和實現技術來完成，其中大多數技術允許用戶從抽象的和無時序（untimed）的初始模型開始，在設計流程中逐漸進行改進和細化，直到設計者最後實現它。

在軟體方面，設計團隊可以選擇屬於特定應用領域的工具和使用特定模擬規範。在硬體方面，設計團隊可以從建立HDL行為模型和使用一般C/C++描述的抽象層級（abstract level）開始工作。在軟硬體兩方面，上述工具允許在無時序的抽象層級建立模型，有些還提供直接的實現途徑。不過，只是在少數情況下，自動產生的程式碼才接近於生產用的程式碼。大多數情況下，設計團隊需要手動實現RTL和軟體設計，只使用抽象模型來對系統的某些方面進行分析。例如，對一個解碼器的不同演算法的選擇評估。但也有極少數例外，例如：允許DSP演算法以微架構（micro-architecture）的圖形來表示，並以輸入這種圖形來實現DSP演算法。而且它能和HDL整合，輸出給Verilog、VHDL和測試工具，可在不同抽象層級之間重覆使用。

除了晶片設計團隊會遇到上述的問題外，系統整合時會遇到的問題也一樣難纏。在RTL和軟體的實現層級（implementation level）上，進行取捨評估是不實際的，因為模擬速度有限，只能考慮幾種替代方案而已。不過，現在有一些新的開發環境能讓SoC設計團隊可以使用模型對實現方案的性能進行「抽象」。這種方法允許藍芽SoC設計團隊在系統層級上持續做功能描述，而與未來的實現細節無關，並藉由改變性能模型，快速嘗試不同的選擇。

基於相同平台的先進設計方法，是以異質架構的方式對功能進行描述和模擬。雖然功能定義通常是藍芽系統設計團隊的責任，但是SoC設計團隊可以在實現階段之前，使用CPU、DSP、匯流排、即時作業系統（RTOS）、記憶體和實現專用硬體/軟體的抽象模型來提供系統架構。

架構模型代表了抽象的性能模型。功能和架構之間的映射，定義了哪些架構的資源是供給計算和通訊使用的。性能模擬模型可由HDL、SDL、C/C++三種描述語言來建立，因此，能提早在實現階段以前，就可以進行高效率的取捨模擬了，而不用像現在必須等到實現階段，才能使用代表實現方法的性能模型對性能做特徵描述或評估。

開發資訊的交流

要注意的是，在一適當高的抽象層級和同一開發環境內，必須為設計工作提供功能攫取（capture）、架構攫取以及映射（mapping），這是很重要的。這為藍芽系統設計商和SoC半導體供應商之間，建立了相互交流的新途徑。更重要的是，他們在保持緊密合作的同時，雙方都還能專注於各自的核心技術開發工作，而不會像現在的系統整合商必須獨自扛起所有的負擔。

上述設計流程（design flow），提供了在早期就能進行系統性能評估的能力。它還在SoC設計鏈（design chain）中，提供了一個高效率的連接點（hand-off point）。同時，功能和架構描述定義了抽象的系統平台。藍芽系統設計者可以改變映射、增加功能，並在產品最後實現之前，在「功能－架構」設計之工程領域（function- architecture design space）中，有效地進行研發。功能的定義與實現的方法是不相關的，其內容可以清楚地告訴藍芽SoC開發商，並進行架構的選擇評估。

在使用性能模擬完成了功能設計研究，並決定出一組最佳的功能/架構方案之後，最重要的就是直接向實現層級的工具組（implementation-level tools）輸出這一資訊。這些工具組包括：硬體/軟體協同驗証工具、編譯器（compiler）以及硬體合成（synthesis）工具。

結語

在相同平台上設計的方法，也支援矽智權不需修改地重複使用。因此，藍芽系統設計商與藍芽晶片設計商之間的設計輸出，必須能夠在硬體與軟體、軟體與硬體以及在硬體領域和軟體領域內，自動建立通訊路徑。也必須有一種「功能－架構」協同設計的方法以及一個工具環境，來提供從抽象系統層級（abstract system level）（作為功能設計研究之用）到實現層級的途徑。這將促使硬體和軟體能從系統層級向實現層級輸出，以及建立通訊合成（communication synthesis），通訊合成是指在每個設計模組（design blocks）之間建立通訊的意思。

以前的藍芽開發商都是孤軍奮戰，未來的藍芽開發商勢必要協同作戰。不過，廠方們各自擁有的開發資源和資訊是否能夠充分公開交流、共享，以及業界之間的資訊或矽智權交流的規範制度是否能夠建立起來，將是藍芽產品能否快速開發的關鍵。