提高嵌入式應用性價比 該如何選擇適處理器核心架構
時間：2016-05-23 來源：未知
現階段半導體芯片商多采用ARM的處理器核心，來制造旗下處理器或微控制器等產品。ARM的核心可分為A、R、M三個系列，各有不同性能，因此芯片商也須依各自瞄準的市場、功耗需求和作業系統等差異，來選擇較適合的核心，藉以制造性價比佳的產品。
現今嵌入式應用內須用到諸多處理器，因此半導體廠商也積極投入布局，舉例來說安謀(ARM)的處理器便廣泛應用于嵌入式領域。ARM Cortex-A系列處理器經常使用在需要多功能作業系統(Rich OS)或高效能的應用中，Cortex-R系列處理器擁有較佳的即時效能，Cortex-M系列處理器則用于微控制器等類型的小型應用。
目前 采用Cortex-M的產品范圍涵蓋非常多樣化的選項，從外型設計小巧、功耗低的Cortex-M0，其使用在深層嵌入、對成本敏感的應用如智慧型感測器 節點上，到應用在大眾市場的微控制器的Cortex-M3及Cortex-M4。佳的則是Cortex-M7，其具備更高的效能，可以執行密集運算的工 作負載，像是訊號處理等。
Cortex-M處理器采用的ARMv6-M和ARMv7-M架構，是更為簡易且邏輯化的程式設計模型，專為簡易使用所設計。處理器核心本身在設定上較彈性，能夠用于更多樣化的實作。
雖然Cortex-M核心的簡易性對大部分的嵌入式應用來說是較佳的優勢，但仍有其他應用需要更多功能、效能更高的環境。此類應用同樣重視效率和耗電量，且 經常需要Linux或Android等類型的平臺作業系統。采用此類型的作業系統，則能夠使用應用范圍更廣、更具多功能且復雜的軟體生態系統，開發新的契 機。
Cortex-M處理器的設計并非針對這些高階的作業系統，因此未包含其所需要的特定必要功能。舉例來說，這些處理器未具備記憶 體管理單元(MMU)，在無法支援虛擬存儲器環境的情況下，當然也就不支援這一類的作業系統。若某項應用需要更多功能的作業環境，首選的通常是較高效率的 Cortex-A核心。這些核心提供平臺作業系統所需的較進階功能，同時仍相當重視功耗，整體來說是更為高階且彈性化的程式設計模型。
有鑒于此，ARM Cortex-A處理器多部署于各種深度嵌入的應用，尤其是在需要Linux或其他多功能作業系統的市場。
圖1顯示Cortex-A處理器目前的應用范圍，重點在于其中的較低功耗核心。本文以此一系列中的新型Cortex-A32處理器為主。
圖1 Cortex-A處理器與架構
Cortex- A32是進入Cortex-A系列較理想的入門款，可用于需要多功能作業系統環境，或從Cortex-A處理器所提供的效能及功能中獲益的應用。該處理器 為目前擁有低功耗的ARMv8-A處理器，為穿戴式裝置、物聯網(IoT)和多功能嵌入式應用，尤其是需要Linux這一類平臺作業系統之應用的較佳選 擇。
搶攻32位元運算市場 A系列新處理器功耗更低
Cortex-A32在ARM架構中扮演著獨特的角色。其采用ARMv8-A架構，但僅支援32位元的運算。圖2顯示Cortex-A32如何融入ARMv8-A架構設定，以及與Cortex-A35的差異。
圖2 Cortex-A32與Cortex-A35比較
Cortex- A35同時采用32位元的AArch32和64位元的AArch64兩種執行狀態，能夠完整提供ARMv8-A架構的64位元功能。另一方 面，Cortex-A32則只采用32位元的AArch32執行狀態。移除了64位元的功能以后，不僅體積縮減，對于不需要64位元功能的使用來說，更能 降低其功耗。盡管嵌入式領域中有許多應用都可從64位元的執行中獲益，但有許多仍著重在32位元，且將在可預見的未來保持現況，而這些應用便是 Cortex-A32的目標市場。
AArch32執行狀態為更早期的Cortex-A處理器所采用的ARMv7-A架構的進化版。據了解，Cortex-A32即使不具備64位元的功能，但仍提供某些重要的強化，因此功耗還是優于Cortex-A7和Cortex-A5。
此外，對于仍采用這些舊版ARM處理器的延伸設計，或以此相同市場為目標的新設計而言，Cortex-A32仍是理想選擇。
AArch32優于ARMv7-A的特點包括：
.新增許多新指令，加密演算功能效能更佳
.新加入Load Acquire和Store Release指令，提供更有效率的存儲器排序功能，符合新的C++11存儲器排序語法
.額外的純量與SIMD浮點指令
.廣泛的系統控制指令
這些額外功能提供更佳的效能，更勝舊版32位元ARMv7-A處理器。
Cortex-A32匯流排介面加入了先進同步擴展(ACE)，因此能通過Cortex-A32來建構完全同步的多重處理系統，提高所需要的更高效能。
假如空間或耗電量為主要的限制，Cortex-A32也有變體版本，特別針對單處理器應用佳化，省略互連邏輯，以節省更多的功耗。
Cortex-A32透過Large Physical Address Extension(LPAE)擴大了定址實體存儲器空間，超越Cortex-A5所提供的32位元(4GB)空間，可提供40位元定址空間。
核心本身也整合其他多項有助于改善功耗的進階功能，包括更彈性化的電源管理、更細微分布的電力區域，并使用保存功率閘級。
ARMv7-M與ARMv8-A AArch32架構比較
下文將比較ARMv7-M與ARMv8-A AArch32的架構特色與差異。
ARMv7-M架構特色
ARM Cortex-M處理器系采用ARMv7-M架構設定，Cortex-M0和Cortex-M0+則采用類似的ARMv6-M架構。
此架構與先前的ARM架構有許多共同的特色，且經過特殊設計，以支援深層嵌入、低成本的即時微控制器應用。所以移除了舊架構的許多功能，但也加入新功能，制造出一個更像類微控制器的程式設計模型。
舉體來說，從舊型處理器(像是常見的ARM7TDMI)的變動可總結如下：
.作業模式的數量從七個以上大幅減少到兩個：Handler模式和Thread模式。其中一項模式(Handler模式)具選擇性優先權限。
.暫存器檔經過簡化。雖然開放供程式設計人員使用的暫存器基本上仍同樣是十六個，舊型架構中所用的備份暫存器復制機制也大幅減少，因此只有Stack Pointer(r13)會在兩個作業模式中加以暫存。備份暫存器為選擇性使用，甚至可以省略。
. 大的變動在于異常模式。由于一般的微控制器應用可能會有大量的芯片周邊中斷，所以標準的巢狀向量中斷控制器(Nested Vectored Interrupt Controller， NVIC)規格會包含在架構中，所有的Cortex-M核心均包含該規格。同樣地，異常處理模式已在包含處理常式位址的向量表上加以標準化。內容的儲存與 回復作業完全在硬體上實作，簡化寫入中斷處理的軟體工作，如此可在實作時達到非常低且可預測的中斷延遲時間。
.ARMv7-M定義選擇性的存儲器保護架構，該架構與某些舊型ARM處理器所用的架構類似。裸機系統或在即時作業系統(RTOS)下運作的系統由于通常不需要虛擬存儲器，因此不支援虛擬存儲器。
.為支援各種即時作業系統的運作和執行，有些標準的芯片周邊也會在架構中加以定義，如SysTick Timer。
.為縮小處理器核心的大小，ARMv7-M處理器的運行限縮到只有Thumb指令集(包含Thumb-2延伸)，僅執行小的子集，進而實現小的核心。
ARMv8-A AArch32特色
Cortex- A處理器采用ARMv7-A或ARMv8-A架構設定。ARMv8-A處理器提供AArch32執行狀態，為32位元ARMv7-A架構的向下相容演化 版。這些架構可實現專門設計用來支援Linux、Android、Windows等平臺作業系統的功能，而這些系統需要虛擬存儲器環境。
其與Cortex-M處理器核心截然不同的特定功能包括：
. 有七個以上的作業模式：User、Supervisor、阻斷要求(IRQ)、快速中斷(Fast Interrupt， FIQ)、Undefined、Abort、System。每一模式皆用于處理特定類型事件(例如IRQ模式便是設計用于處理IRQ中斷)。 AArch32亦支援Hyp和Monitor這兩個額外的模式，這兩個模式分別用于虛擬化及ARM TrustZone技術。
.除了可用的登錄數量相同(16)，AArch32還有許多與上述作業模式相關的“備份”暫存器。進入相關的作業模式時，這些暫存器將取代User模式下的暫存器。如此可簡化許多異常處理工作，但也表示機器的管理和初始化工作將增加。
.其異常模式極為不同，其原型存在于早的ARM架構裝置中。具體來說，向量表包含一組可執行的指令集，而不是位址，且內容的儲存與回復Restore工作幾乎完全交給程式設計人員執行。
.大的差異是加入了存儲器管理單元，可執行核心所核發之虛擬位址，以及存儲器系統所需要的實體位址間的轉譯。如此便能實作完全的隨選分頁虛擬存儲器環境，以供Linux等平臺作業系統使用。
ARMv7-M與AArch32的差異
從采用Cortex-M處理器的系統轉換到采用Cortex-A32處理器時，有許多新功能值得關注。
雖然這兩種架構有許多類似之處(如備份暫存器和指令集之間有許多相同點)，但重要的是ARMv8-A架構的AArch32執行狀態所含的許多功能，均是以舊型架構的功能為基礎。
接下來說明AArch32所具備，但為ARMv7-M所無或差異極大的功能。
作業模式
如 圖3所示，ARMv7-M只定義兩個作業模式：Thread模式與Handler模式。若無需要，Handler模式可選擇性取消優先權限，雖然這項功能 未必須要在軟體內使用。Handler模式適用于處理異常，Thread模式則用于使用者處理程序。這兩個模式轉換基本上是自動的，會在特定事件下發生， 如圖3所示。例如，發生異常時會自動進入Handler模式，異常處理完成時則會退出Handler模式。SVCall指令為主要的方法，軟體用其來進入 Handler模式(也可將啟用的IRQ設定為待處理狀態，以執行Handler)。
圖3 ARMv7-M作業模式
圖4則顯示AArch32執行狀態支援的作業模式。與ARMv7-M相較，AArch32有七個基本模式，其中五個指定用于處理特定異常。例如，取得FIQ異常時會進入FIQ模式;若發生未定義指令等情形，會進入Undef模式。
圖4 AArch32作業模式
模式的轉換通常為自動發生，但也可在Current Program Status Register(CPSR)中寫入Mode欄位，用軟體控制來完整切換模式。其細節描述如下。與SVCall指令類似，SVC指令用于讓軟體引發SVC異常并進入SVC模式。
圖4中未顯示AArch32所支援的另兩個模式(為節省空間)，也就是Hyp模式(用于Hypervisor)與Monitor模式(用于TrustZone安全性)。相關主題較為復雜，本文不予討論。
備份暫存器
圖5顯示ARMv7-M和AArch32的備份暫存器。可看出，許多暫存器為共有，因為這兩種架構均是沿襲自ARMv6及先前的架構。
圖5 ARMv7-M登錄集
多數指令可存取十三個通用型的暫存器r0-r12。在這兩種架構中，r13保留為Stack Pointer(SP)，r14保留為Link Register(LR)，r15則保留為Program Counter(PC)。在ARMv7-M中，這些特殊暫存器的存取僅限于某些反映這些暫存器功能的特定使用狀況;在AArch32中，這些暫存器的存取 則類似任何其他通用的暫存器(雖然變更Program Counter的數值可能造成非預期的副作用)。
ARMv7-M指定小部分額外特殊用途的暫存器PRIMASK、FAULTMASK、xPSR、CONTROL和BASEPRI，用于控制及設定處理器，及用于管理異常處理。
指令集
圖 5與圖6分別是ARMv7-M與AArch32登錄集，兩相比較可看出AArch32也提供許多與特定作業模式關聯的暫存器。這些暫存器會在進入相關的模 式時與其在User模式下的暫存器交換。除了少數特殊指令，其他指令均無法存取這些暫存器，但也無法直接存取。其數值在模式變更時亦會保留，有助于處理異 常。每個異常模式皆有自己的專屬SP，每個異常均可在獨立的堆疊上處理，因此異常處理的程式設計更為穩固且安全。取得異常時，相關模式下的LR設定為異常 傳回位址。
圖6 AArch32登錄集
每個異常模式下會出現的還有叫SPSR的額外暫存器。SPSR用于在進入例外時取得目前CPSR數值的快照，搭配LR使用下，可提供自動化的內容儲存。
AArch32圖中未顯示Mon和Hyp模式，其各自支援備份暫存器的R13和R14，如同其他的模式。
在Cortex-A中，另有一個與ARM NEON SIMD指令集(如下所述)相關的備份暫存器，共包含三十二個128位元寬度的暫存器。每個暫存器均可定址為字組、雙字組或四字組，且NEON指令集從位元組到四字組均支援向量作業。
異常模式
這兩個架構的異常模式有相當大的差異，兩者均支援內部與外部異常，可由系統事件或外部周邊中斷所執行。
ARMv7-M支援與傳統微控制器極為類似的模型，所有外部中斷分別透過包含處理常式位址的向量表來向量。
AArch32 支援的模型則類似舊型ARM架構，當中只有八個有獨立向量的異常類型。向量表包含可執行的指令，其通常為直接連往合適的異常處理常式的分支指令。僅支援兩 個外部中斷來源：FIQ和IRQ。一般只會有一個高優先的中斷連接至FIQ，其余則連接至IRQ。亦即系統必須整合軟體分配器，或如同現代化系統所常見 的，包含可用個別向量位址進行程式設計的Vectored Interrupt Controller(VIC)。
許多 Cortex-A系統包含采用ARM之Generic Interrupt Controller(GIC)架構的標準中斷控制器。GIC可作為許多實體中斷和ARM核心的兩個中斷輸入(FIQ和IRQ)之間的介面。其可處理優先 順序的決定、遮掩、個別中斷啟用/停用和搶奪。
指令集
ARM指令集自25年前在ARM1首次推出后已經過許多演進。Cortex-A處理器實際上支援兩個指令集，每個指令集均有許多延伸。
.ARM指令集
ARM 指令集以第一個ARM處理器所支援的原始指令集為基礎，但已經過多次延伸。其為load-store指令集，內含獨立指令群組，可用于資料處理、存儲器存 取、系統控制及控制流量。現代的ARM指令集具有高效能，且范圍廣泛。此指令集中的所有指令均以固定長度的32位元字組編碼，且字組邊界必須對齊。
.Thumb指令集
Thumb 指令集為ARM指令集的子集，其中每個指令均編碼為16位元的半字組，其半字組邊界必須對齊。Thumb指令集的原始概念是為了在編譯C之類的高階語言 時，縮小常用指令的大小，藉此改善程式碼的密度。指令縮小后，由于指定的快取行內可放入更多指令，因此也有助于從指令快取內執行。
.進階SIMD延伸集
進階SIMD延伸集(Advanced SIMD Extensions)亦稱為NEON，是大型的指令集，可利用延伸暫存器組合提供SIMD向量處理功能。
.向量浮點(VFP)
VFP指令集在與NEON相同的備份暫存器上執行，其可提供高效能的IEEE-754相容單一與雙重精準浮點作業。
.Thumb-2技術
Thumb-2為延伸集的名稱，在ARMv6T2(首先出現在ARM1156T2-S處理器)加入到Thumb指令集內。其為混合長度的指令集，結合Thumb的程式碼密度與ARM指令集的較高效能與彈性。
假 如使用者已利用Cortex-M微控制器進行開發，應該會對Thumb-2很熟悉。這些程式碼在從小(Cortex-M0和Cortex-M0+)到 大(Cortex-M7)的各種子集中僅支援Thumb-2。轉移到Cortex-A處理器，能為程式碼生成開啟許多可能性。
一般來說，多數針對Cortex-A處理器編譯的高階程式碼將以Thumb(含Thumb-2)為目標。因此編譯人員可獲得大的自由，在有多重選擇下合理選擇所要使用的指令，在針對程式碼空間進行編譯與針對效能進行編譯兩種情況下實現高的差異。
ARM指令集通常用于必須要達到高效能的程式碼區段。這些區段有時可在組譯器內手動編碼，而ARM指令集通常會是好的選擇。
NEON指令集可用下列多種方式存取：
.有程式庫支援常見的數學與分析功能及演算法。
.編譯器支援完整的內部功能集，允許從C直接存取完整的NEON指令集。透過這種方法，NEON作業便能以便利的方式與C程式碼交錯處理。
.NEON可直接在組譯器內手動執行。
.編譯器亦支援反覆回路的自動向量。只要遵循一些簡單的指示來編寫程式碼，即使是稍顯復雜的回路，編譯器也能有效執行及向量化。
如果使用者熟悉ARMv7-A處理器，應該也會注意到ARMv8-A加入一些額外的指令。
.密碼編譯延伸模組(Cryptographic Extensions)
這些指令為ARMv8-A新加入，目的是為了有效實作常見的加密功能建構區塊演算法。這些延伸是在NEON備份暫存器上運作。
.Load-Acquire和Store-Release
這些新指令符合C++11存儲器排序語法，能提升編譯效率。也可用來減少對資料側存儲器局限的需求，并部分減少與其相關的工作量。
還有一些其他與浮點和限制指令有關的小型延伸。
虛擬存儲器支援
支援完整虛擬存儲器環境為ARMv8-A主要功能之一，正是透過這項功能，這些裝置才能支援Linux和Android等平臺作業系統。因此，虛擬存儲器功能經常也是在這些核心中進行選擇時為關鍵的條件。
虛擬存儲器環境可讓作業系統管理存儲器時更富彈性，像是使個別處理程序動態延伸堆疊區，啟用個別的程式碼，讓資料區能視需要在外部儲存空間內部和外部進行分頁，讓個別的使用者處理程序可以檢視完全相同的系統存儲器配置圖。
為發揮作用，虛擬存儲器在處理器所配發的每個位址上加入了“轉譯”，如圖7所示。軟體會在“虛擬位址空間”執行，還有一個名為存儲器管理單元的區塊會將其轉譯為實體位址空間。
圖7 虛擬存儲器
為了使作業系統完整控制存取權限等內容，以針對系統內的各項使用者工作及作業系統本身建立新的虛擬存儲器配置圖。每項工作可當作系統內唯一的工作，在自己的虛擬存儲器空間內執行。只有作業系統知道工作程式碼及資料區在外部實體存儲器內的實體位置。
在切換工作時，作業系統的其中一項任務就是重新設定存儲器管理單元，以啟用傳入工作所用的程式碼及資料，同時讓傳出工作的存儲器暫時無法存取。如此可強制區分工作，為安全且彈性的系統的必要元素。
此 處不會提供完整說明，ARM處理器內的存儲器管理單元使用保留在外部存儲器中的“分頁表”所含的資料來帶動及控制轉譯。系統整合多項佳化作業(例如，包 含Translation Lookaside Buffers，或簡稱為TLB，能為近使用過的轉譯建立快取，以減少讀取分頁表的工作量)，可盡量縮小轉譯處理程序的工作量。
從ARMv7-M到ARMv7-A的軟體轉移
多數的高階軟體皆須要簡單的重新編譯。下列區域的軟體則須詳加注意：
.重置程式碼及其他例外處理常式
如果使用作業系統，這部分的工作將由作業系統所提供的工具來處理。多數情況下，常見作業系統的連接埠將透過公開網域散布或裝置供應商提供。
因異常模式差異較大，因此須重新寫入中斷處理常式。作業系統同樣會提供基礎架構來完成這部分工作，藉以簡單地重新編譯多數中斷處理常式的主體。
.周邊驅動程式
從RTOS轉移到Linux這類的多功能平臺作業系統時，應用程式碼及周邊驅動程式須更明確地加以區隔。
.系統組態功能
采 用Cortex-M與Cortex-A的裝置在提供系統組態與控制功能存取方面有較大的差異。Cortex-M處理器通常透過具名或存儲器對映的暫存器來 設定，可直接讀取及寫入，以達成所要的功能。Cortex-A處理器(為Cortex-A32所支援的AArch32執行狀態)則是透過“系統控制協同處 理器”來支援設定。概念性的“協同處理器15”包含大量的設定暫存器集，使用專屬的指令進行讀取及寫入。非由作業系統執行的系統組態功能則須重新寫入，以 完成這部分的工作。也就是說，作業系統通常會提供應用程式介面(API)，以用于須要由使用者介面存取的功能。
.匯編程式碼
很 明顯地，匯編程式碼也須特別注意。因為寫入匯編程式碼的其中一個主要原因，便是為了獲得高的效能，因此必須詳加檢驗這些功能，確定重新寫入能在存取 NEON等某些延伸指令集功能時提供好處。若舊型的匯編程式碼已使用“Uniform Assembler Language(UAL)”語法寫入，則多數程式碼將簡單地重新匯編為ARM或Thumb指令。
