ARM 生態有何優勢?席捲行動產業之餘,也開始對其他運算產業產生威脅?

ARM 是家專門提供處理器架構授權的公司,其企業發展史其實就等同於高效能低功耗運算架構的革命史,過去通用處理器的演算架構的發展,向來都是以性能為優先考量,然而 ARM 反其道而行,以低功耗、可靠性能,提供業界易用的架構授權產品與方式,在業界打下口碑。

ARM

Intel 最近退出智慧型手機市場,並終止部分 Atom 產品線,也證明了發展低功耗架構,尤其是針對行動應用的低功耗架構並不是那麼簡單的事情。

而在行動運算架構激烈演進的近10年內,ARM 更是成為整個包括智慧型手機、平板電腦、智慧型穿戴裝置發展的重要推手。而後來的智慧家居、無人機、自動駕駛、智慧城市等基礎建設與應用,或應該說,幾乎所有與智慧兩個字掛勾的應用,都與 ARM 脫不了關係。

雖然 ARM 重要性如此之高,但其身為英國公司,其實作風也是出了名的低調,而在幾年前 Intel 把 ARM 拱到檯面上作為最大假想敵攻擊之時,ARM 也轉變心態,開始為客戶站出來面對並教育消費大眾,提升消費大眾對其架構的應用與選擇的認知。

當然,身為一板一眼的英國公司,不擅長作秀乍看之下是個不小的缺點,然而不擅長作秀,轉而把資金集中用來改善架構,或者是像近年併購多家公司來充實既有產品線的技術完整性,藉以改善競爭力,我們也不得不贊同 ARM 的實事求是態度,在這個過度依靠行銷的世界裡,的確還是有其獨到之處。

 

有趣的處理器架構命名潛規則

如果各位讀者接觸過半導體相關產業,應該都會對 ARM 的幾大產品線相當熟悉,包括ARM X、Cortex-AXX、RXX、MXX 等(X 代表數字),其採用客戶、規格、性能表現、應用,多能略舉一二,如果舉辦個有獎問答,大概就是獎品會被瞬間領光光的程度(如果各位讀者有興趣,我們可以想辦法凹 ARM 配合舉辦唷,有興趣請留言,揪咪)。

不過各位不知道有沒有發現,ARM 在通用 CPU 核心的部分,有越來越不喜歡用偶數命名的趨勢,過去在古早的 ARM X 世代,在市場上取得成功,甚至到現在還佔有一席之地的架構,基本上都是奇數世代的產品,也就是 ARM7、ARM9,而 ARM11 雖不算淵遠流長,但也好過 ARM2、ARM6、ARM8、ARM10 沒有、或僅有少數一兩家客戶採用的狀況。

進入 Cortex 世代,最早推出的 A8、A9,接著 A7、A15、A12,以及從 A12 修改而來的 A17,到 A53、A57 與 A72 等,可以發現奇數代號產品遠多於偶數代號產品,就產品本身的市場成績,偶數世代表現也多半不如奇數世代。當然,從命名規則來看產品成敗也不是絕對正確,舉例來說,Cortex-A8 不算短命,A12 和改名版 A17 客戶採用率也遠較其他客戶低,A72 從推出到現在也還是高階主力之一,反而 A57 在行動應用只熱了短短一年,後來轉而衝刺伺服器產品。

加上已經公布,但還沒有實際產品推出的 Cortex-A35 與 A32,目前整個 Cortex 系列,奇數命名產品就佔了三分之二,加上新的高階架構 A73,ARM 對於奇數偶數命名的偏好,其實還是相當顯而易見。

 

標準架構與客製化核心

ARM 的提供的產品服務包括了標準架構授權,以及指令集授權,標準架構指的就是符合類似 ARM X、Cortex-X 之類命名規格則的產品架構直接授權,指令集授權則是針對 ARMvX(目前最新的是 64 位元的 ARMv8-A)指令集進行的授權,客戶只要指令集相容,其他計算單元的配置、管線、周邊的溝通能力、匯流排架構等等,都可以自行調整,甚至要整合自己或第三方運算架構,ARM 都悉聽尊便。

所以哪一種比較好?其實沒有定論,以 Hisilicon 曾經發表的看法為例,他們覺得在行動應用這塊領域,每年市場就產品規格與性能要求的變化幅度太大,需要大量研發人力進行高度客製化的指令集授權方式恐怕在面對市場的競爭會緩不濟急,因此將堅持標準架構,反而他們認為在伺服器等要求可靠性與差異化兼具,並具備長期支援能力的產品類型,比較適合指令集授權方式。

qualcomm snapdragon 810

Qualcomm 雖然看起來相對激進,在高階智慧型手機方案主打自有架構,也就是指令集授權方式,但 Qualcomm 也不是沒有跌過跤,在 ARM 架構剛邁入 64 位元時代之初,Qualcomm 因為誤判 64 位元的熱度與滲透速度,其研發到一半的自有次世代核心僅支援 32 位元運算,不得已只好半路喊停,緊急採用 ARM 的標準架構 Cortex-A57 來推出高階 64 位元產品。當然,Qualcomm 第一個高階 64 位元產品,也就是 Snapdragon 810 ,其表現如何,市場已有公評,這邊就不多說明,但也相對驗證了 Hisilicon 的看法。

Qualcomm 後來的自有 64 位元 Kryo 核心雖洗刷了前恥,不僅效能上打 Apple,功耗和發熱控制能力也十分出色,也重新獲得了整個市場的認可,然而這是在犧牲了一整個世代的市場以及客戶名聲換來的,代價不可謂不高。

標準架構針對的是對於產品時效非常注重的客戶,由於整個設計都已經經過驗證,基本上把調整好的設計直接丟給晶圓廠就能製造出來,採用指令集授權的自有架構則從設計、驗證、製造、軟體整合等都要自己來,成本高不說,開發時程也遠高於採用標準架構。

那麼為何基於指令集授權的自有架構出貨佔比反而有增加的趨勢?如果以 Apple、Samsung、Qualcomm 這三家主要的客製化架構大廠在 2016 年第一季的相關產品出貨量來看,其在 600 美元以上的高階終端市佔就超過8成,這時候各位可能心裡有了疑惑:標準架構不是成本和時程比較有優勢嗎?

arm partner

高階通常更重視差異化更甚於成本,換句話說,高階消費者重視的是廠商採用的架構能帶給消費者的應用體驗優勢,而非純粹售價考量,再加上既有的產品與方案雙重品牌效應結合,消費者自然會有這樣的選擇取向。

但值得注意的是,即便是高階平台,若能在包括性能、應用、支援性、成本、開發時程掌握度等均衡性拿捏好,其實未必非用指令集授權自己搞核心不可,畢竟 ARM 標準架構同樣可以連接各種不同的處理單元,架構本身也有相當的調整彈性,而當大部分的廠商都在追求指令集授權的高度客製化架構的時候,反而使用標準架構的廠商就擁有了獨特性,所以不同時期、不同選擇,沒有錯的一方,端看使用的策略而定。

而在重視成本與時程控制更甚於產品差異化的中低階市場,標準架構可以說佔了絕對優勢,沒有人會在這塊市場貿然採用指令集授權。

 

更具彈性的SoC設計方式:big.LITTLE

big.LITTLE 已經是非常普及的設計方式,配合調整得當的溫度與功耗閥值設定,在性能與功耗的表現可以達到相當不錯的表現,目前中階方案6核以上配置的產品幾乎都基於此技術,或者是類似概念:比如說 8 核 Cortex-A53 的產品分為 2個叢集(Cluster),以時脈一快一慢的設定來配置,這也符合 big.LITTLE 的定義。

soc

除了快慢核心的搭配以外,big.LITTLE 最簡單也最基本的定義,就是 A57 或 A72 之類的大核搭配 A53 或 A35 之類的小核,整合在同一顆 SoC 裡面。而搭配數量的話要看匯流排能夠支援的核心數量而定,在最新的 CCI-550 中,可以支援到 24 個核心,以 4 個核心為一個叢集,那麼可以創造出 6 個大小核的搭配方式,相較於現有 CCI-500 中最大 4 個叢集的限制可說寬鬆了許多,如果 MediaTek 想要推出整合 24 核心的 Helio X40 或 X50,目前的 CCI-550 會是最佳選擇,至於有沒有必要?再說吧。

但 big.LITTLE 有什麼實際應用上的好處?

這要從 SoC 功耗控制以及性能表現的均衡性來看,SoC 裡面的大核,通常靜態功耗和動態功耗都很高,因此在非必要時,最好不要使用,遇到少數關鍵應用再打開即可,而小核的靜態功耗和動態功耗都比較低,因此適合用來負責處理各種全時開啟的前景及背景服務,而因為靜態功耗低,且為避免系統因為開關核心而造成遲鈍,小核通常都保持開啟狀態,準備好突來的運算要求,而當負載超過一定的閥值,大核才會介入提供運算能量,避免系統操作體驗不流暢。

那問題來了,只用四個或八個大核,不用的核心就關掉,那不是更省事、架構也更單純?然而大核並不適合隨時保持在開啟狀態,在主流行動作業系統中,一定要有核心維持常態開啟,若僅有大核,即便時脈可以動態調低,靜態功耗也會因為核心的規模較大而明顯較高,且因為行動作業系統的限制,處理器核心時脈的動態調整其實不夠線性,時脈的調整無法完全真實反應負載,加上通常會因為要保持系統的流暢性,而有性能「供過於求」的現象,造成動態功耗偏高,加上常態開啟而來的靜態功耗,系統整體功耗表現就會比較差。

因此,相較起一般的多核架構,big.LITTLE 能夠提供更好的功耗彈性,在系統有需要時,也能讓全部的核心同時運作,換取更高的性能表現。

 

從大廠著手尋求伺服器應用領域的突破

ARM 在伺服器應用也投入了相當多的精力,然而伺服器需要更多應用與生態的支持,在 Intel 已經掌握伺服器市場超過 9 成市佔的情況下,設備代工廠、應用廠商不敢貿然支援 ARM 體系也是理所當然。

然而 ARM 還是有突破之道,首先不是所有的客戶都對 Intel 方案的成本和其他性能或功耗表現都很滿意,而這些客戶中又有部分客戶擁有自主開發應用的能力,比如說 Google、Facebook、Amazon,甚至 Microsoft 這些潛在客戶對自有伺服器有著相當高的興趣。

giga arm server

事實上,Amazon 已經推出自有的 ARM 伺服器晶片,Google 則是在 2016 年初開始和 Qualcomm 合作,發展基於 ARM 的伺服器晶片, Facebook 雖然在 2016 年最新的伺服器採購中仍選擇了 Intel 基於 Xeon-D 的方案,但 Facebook 選擇的是 Intel 的低功耗伺服器晶片,而低功耗運算領域其實應該是 ARM 擅長的領域。

大廠與 ARM 或 ARM 的客戶合作發展伺服器方案,雖並非都是真的因為大廠想要轉換平台,部分原因也是作為與 Intel 討價還價的籌碼,但如果 ARM 能夠在這類的競爭中脫穎而出,獲得大廠的全力支援,那麼整個產業會對 ARM 伺服器產生更大的信心。

從 CPU 跨足到 GPU

ARM 自 2007 年進入行動 GPU 市場,其實最初在規格表現方面並沒有特別突出,且因為既有的 GPU IP 不論在應用生態,或者是品牌認知度方面,都已經相當強勢,也因為信心不足之故,ARM 的伙伴對採用 ARM 併購而來的 Mali IP 也顯得興趣缺缺。

2011年,Samsung 大膽選擇 ARM Mali-400 作為高階應用處理器繪圖核心,並以之為基礎推出 Galaxy S2,出貨量突破 4,000 萬支,成為 Mali 架構最大客戶,Android 平台上遊戲應用的支援度也隨之增加,打下基礎後,ARM 也開始攻城掠地,逐步侵蝕 Imagination 與 Qualcomm 繪圖架構的市場地位。

在2014年,ARM 登上全球行動 GPU 架構的市佔冠軍,遠遠超越 Qualcomm 與 Imagination,跟著在 2015 年也延續此態勢。然而 ARM 的 Mali 架構相較起對手的架構已經有點老舊,2016 年雖然截至目前市佔仍穩居第一,但是單位運算性能以及支援特性方面,與對手相較之下基本上已經不佔優勢。

arm mali gpu

因此,2016 年 ARM 推出全新 Bifrost 架構的 GPU 核心 Mali-G71,除了維持過去的高效率繪圖處理能力以外,也要完整支援 HSA 的一致性運算平台,可以和 CPU 共同運作在同一快取記憶體系統中,藉此強化 GPU 與 CPU 的協同運算能力,提升客戶方案的競爭力,並在包括 VR / AR 、高階遊戲應用以及伺服器應用領域中創造更好的市場機會。

 

行動 VR 生態 ARM 要翻天覆地

從 Computex 2016 中 ARM 所發表的處理器及 GPU 架構中可以發現,除了強調在性能有所改善外,功耗表現更是絕佳,尤其時過去高階 ARM 架構應用處理器在高負載運算時都會遇到的性能下降問題,ARM 這次都有信心能夠徹底解決(當然,前提是要配合他們推薦的規格設計與生產製程)。

mali-g71 efficiency

我們都知道,VR 應用,尤其是 VR 遊戲,如果系統無法維持穩定的性能輸出,那麼畫面的延遲很容易就會造成頭暈現象,而且遊戲開發商也很難去維持遊戲體驗的一致。如果 ARM 能夠徹底解決這個問題,那基於 ARM 系統生態,包含手機、平板,或者是獨立的 VR 眼鏡,相關 VR 應用就會因為平台的性能和可用性的改善,強化整體使用體驗,市場也將有機會大幅成長。

雖然 ARM 的客戶不一定都會採用 ARM 的標準架構,尤其高階市場上,基於指令集授權的高度客製化架構有越來越普及的趨勢,但既然 ARM 能夠提出這麼有競爭力的架構,其客戶當然也就不敢隨便亂做。

所以 ARM 推出這個架構的最大受益者是誰?首先就是全體消費者了,終於可以擺脫過去高階方案容易因為過熱或者其他最佳化方面的問題而不夠穩定的性能表現;其次就是採用 ARM 標準高階架構的客戶,畢竟不用花太大的成本就可以獲得這麼明顯的架構改進,肯定對其終端方案的競爭力有極大的幫助;而最後,基於指令集授權的客戶方面,則是會受到鞭策,並持續花重金改善他們的自有架構,避免被 ARM 標準架構趕上(這算受益嗎XD)。

 

不是四肢強化,就不需要腦袋

雖然業界對於 CPU 核心的發展抱持著悲觀的態度,尤其是 PC 以及行動應用平台都已經有性能過剩的聲音出現。而 ARM 努力發展周邊的 IP,包括 GPU、多媒體編解碼、即時加解密等功能,似乎也都讓 CPU 的角色更為弱化。

但事實上,CPU 作為系統的主控核心,必須肩負起統籌系統 I/O 以及各種資料的傳輸與融合處理,且因為處理器的設計要考量未來的性能需求,必須保留有一定的餘裕空間,而不是只針對目前的應用來考量性能需求。

未來包括行動應用在內的各種智慧型終端,必須兼顧更多的通用運算需求,包括人工智慧、視覺處理與實景辨識能力、企業常用的大型辦公應用,甚至伺服器中的資料庫處理、運算等,以 CPU 為代表的通用運算還是有極為重要的地位,雖然屆時也會有更多的周邊運算架構來協助,但 CPU 本身的能力也要夠強,否則將可能成為系統中的瓶頸,畢竟運算架構要看整體的搭配,每個環節都必須有相對的強度才能肩負起未來越來越繁重的應用負載。