如果您認為CPU對片上系統（SoC）而言就像汽車的引擎一樣，你知道你不會將大眾汽車的發動機放在悍馬車上，并期望它能發揮作用。同樣，法拉利發動機也不適合。盡管法拉利可以為悍馬發動機提供類似的馬力，但由于缺少扭矩，它可能會失效。

對馬力的簡單評估與在汽車世界中一樣，在選擇CPU時會產生誤導。有針對所需功能的最佳解決方案。SoC中的CPU選擇也是如此。很多時候，設計人員僅根據系統架構師對特定CPU的知識和過去的經驗來選擇CPU。

在決定使用哪個CPU時，設計人員應考慮總體系統指標，例如：總體設計的復雜性，設計重點，保護，性能，功耗，尺寸，成本，工具和中間件可用性。

設計的復雜性有助于確定要使用哪個CPU。例如，如果設計要求部署一臺狀態機，并帶有來自少量外圍設備的中斷，則小型CPU和/或微控制器（例如8051或Z80）可能是最佳選擇。許多系統（例如尋呼機）最初可能適合此類別。內存占用空間小，信號緩慢，電池消耗必須非常低。

算法及其相互作用將決定設計的復雜性，也可能確定其是否需要實時操作系統（RTOS）。通常，隨著應用程序復雜性的增加，對更大位寬處理器的需求也隨之增加。

設計正在被重視，并且復雜性不斷增加；那個2000年的傳呼機可能需要在2003年播放MP3，因此8位CPU可能不足以應付當前的任務。設計包含的接口數量是一個很好的指標。例如，在我們的傳呼機中，最初有兩個主要界面，用戶界面和無線電鏈接。在添加MP3播放器的設計中，我們將需要添加用于存儲和傳輸數據的內存接口，以及用于播放數據的音頻接口。在這個例子中，系統的復雜性從最初的概念開始就大大增加了，如果我們考慮將來可以將設計部署到哪里，我們可以重用許多相同的設計。

確保您留有增長空間。今天，您的8位設計可能適合MP3播放器。但是，當在具有更高帶寬外圍設備的機頂盒應用程序中重用設計時，您可能需要重新設計完整的解決方案，以遷移到基于ARM，MIPS或PowerPC的應用程序。體系結構以應對新的約束。

系統可能需要保護自己免受外部攻擊，甚至免受自身攻擊，這意味著CPU可能需要包含內存管理單元（MMU）來解決此問題。虛擬內存允許受約束的程序訪問整個系統，而不受信任的程序只能訪問分配給它們的內存。3G手機（具有Internet連接的手機）是需要保護的典型示例。由于惡意程序會使您的手機崩潰，因此設計人員不再能夠使用缺少MMU的CPU。盡管MMU并沒有消除潛在的系統故障，但它減少了難以發現的系統故障的數量和頻率。

三種主要的CPU體系結構圍繞具有16位，24位和32位地址總線的8位，16位和32位數據寄存器構建。這些體系結構之間的主要區別在于，一個特定的寄存器可以容納的信息量以及可以直接尋址的信息量，如下所示：使用8位數據寄存器和16位地址總線，CPU可以擁有64k的地址空間；一個帶有16位數據寄存器和24位地址的地址空間可以具有16兆字節的地址空間；而具有32位數據的32位地址將具有4 GB的地址空間。

為什么嵌入式系統曾經需要訪問4 GB的地址空間？答案很簡單：由于要求系統執行更復雜的任務，因此運行的代碼的大小和復雜性都會增加。Z80上CPM的早期使用了存儲內存和頁面交換的過程來運行8位計算機上更復雜的程序。由于64k的空間不足，設計人員通過覆蓋內存和頁面以使更多CPU占用空間，使系統變得更加復雜。

對于許多設計而言，24位地址總線似乎已足夠。但是，有幾個因素將設計人員驅使到32位地址空間，包括保護和指針。為了進行保護，具有虛擬內存的CPU可以使用整個地址范圍將物理內存劃分為單獨的虛擬空間，從而可以保護指針免受錯誤的侵害。無需索引即可使任何寄存器成為指向內存的指針的功能簡化了軟件。

選擇CPU會對整個系統的性能產生極大的影響。具體來說，緩存，MMU，流水線，分支預測和超標量體系結構等功能都會影響系統的速度。根據SoC的需求，可能需要使用這些功能來實現系統的最佳性能。

SoC的最終用途將決定您的設計消耗多少功率。如果您的設計是電池供電的，則CPU將需要盡可能節省功耗。例如，某些CPU具有睡眠。這些模式允許CPU在空閑時通過關閉CPU的數量來暫停操作并消耗更少的功率。不同的CPU執行同一任務的結果不同。

CPU的成本可以通過幾種方法來衡量。首先，存在IP成本，其中包括為SoC和任何衍生產品獲得IP的成本。然后是系統集成成本，其中包括可用于SoC設計和實現的工具。最后，您必須確定CPU變體是否經過硅驗證，以及在SoC使用的總線體系結構中是否可用。

RTOS和中間件的可用性也可能決定您的選擇。例如，在設計PDA時，您可能需要適用于Linux的中間件，但是選擇虛擬操作系統將決定您要從小型非MMU CPU遷移。

此外，如果設計需要圖形系統或文件系統，則RTOS的選擇將決定CPU的類型。許多RTOS供應商針對特定的家庭，而其他人則保持不變。大多數8位CPU都具有簡單的調度程序，盡管這些調度程序適合于消耗很少的外包代碼的小型設計，但不適用于消耗任何數量的外包代碼的設計。解決方案的外包將確定要使用的RTOS，進而決定將支持哪些CPU。

其他考慮因素包括：您需要哪些工具來進行設計，并且它們可用于您可能使用的標準ANSI C / C ++編譯器嗎？您將如何在硬件/軟件協同仿真環境或SoC中調試設計？是否存在JTAG端口，CPU是使用該通道進行調試還是調試需要專用的串行端口？選擇更高級的語言（例如C ++）或從UML中的設計生成的代碼也可能表明您需要更高的總線寬度和時鐘頻率來處理代碼的大小和復雜性。

如果將SoC劃分為幾個通過松散連接的FIFO或串行通道進行通信的處理器子系統，則可能會更好。許多設計都集成了數字信號處理器和RISC CPU，以分擔工作量并簡化每個處理器域的設計。

現代SoC設計為系統架構師提出了新的挑戰。選擇CPU不再是瑣碎的事情。通過使用諸如總體設計的復雜性，設計重用，保護，性能，功耗，尺寸，成本，工具和中間件可用性之類的指南，設計人員可以簡化決策。
責任編輯：tzh