用 FPGA 技術更新傳統系統是許多嵌入式系統設計人員都知道的場景。但現有設計確實需要更新，這其中就包括連接互聯網、 IoT等。當然，我們也需要進一步增強安全性。尤其考慮到目前人們熱衷于人工智能，大家對深度學習推理或機器視覺又有了新的需求。

盡管現在已將系統整合至物聯網，但仍然面臨一個迫在眉睫的問題——這些更改將對系統硬件造成影響。直接使用 CPU 可以緩解所有的問題。但對于小型嵌入式設計（一開始就只有一英寸的小外形）來說，由于存在成本、功耗和散熱方面的限制，這種蠻力法可能行不通。此時，必須采用 FPGA 方法。

事實上，系統中通常有一個老舊的小型 FPGA 負責執行實用工作：充當端口擴展器或設備控制器。然而，現在的低端 FPGA 可以充當硬件加速器，將新的計算要求拉回至現有系統處理器范圍之內。

采取下一步行動

我們需要采取進一步行動，考慮將系統（或子系統）的 CPU 或微控制器單元 (MCU) 也整合到 FPGA 中是否可行？顯而易見，答案是“當然不可行”。眾所周知，FPGA 中的軟 CPU 內核尺寸大、速度慢、價格貴。除了對于重要的嵌入式系統來說，這些概括性說法都不對。

我們不是在討論擁有強大 CPU 性能的系統。（比如 Arm* Cortex*-A53 內核集群。）在硬件中包含此類 CPU 集群的中端 FPGA，但該主題不在本文介紹范圍之內。今天我們討論的是處理器適用范圍更廣的系統（或總體設計中的子系統）：微控制器中的 Cortex-M 級內核，或真正的傳統 CPU，如 68000。通常情況下，這種老舊處理器不適用于系統設計，因為它們始終不愿意接觸古老、文檔不完整的代碼，直至最后生命周期結束被迫淘汰。我們要介紹的是，通常可以將這種小型或老舊 CPU 整合至低端 FPGA 中（圖 2）。

圖2.小型現代FPGA可以吸收舊設計中所有的傳統處理器

“芯”起點在哪兒？

如果您有用 C 或 C++（最好是通過原始測試工作臺）編寫的文檔化源代碼，那么情況將對您非常有利。您可以從適用于在 FPGA 中進行軟實施的整個 CPU 內核選項中進行選擇。然后，還可以針對所選的 CPU 重新編譯并測試代碼。

遺憾的是，測試結果并不總是樂觀的。過去，微處理器的編譯器并不總是適合嵌入式設計，尤其是對于存在實時限制的子系統。老代碼或保守型工程師編寫的代碼，可能完全是用匯編語言編寫的。現代代碼主要是用 C 語言編寫的，其中關鍵例程用匯編語言手動編寫。無論采用哪種語言編寫，都至少會有一部分代碼鎖定在特定的指令集架構中。

其次，需要謹慎考慮硬件獨立性程度，不是語言方面，而是編碼風格方面。在過去節省代碼空間和縮短延遲至關重要的時候，往應用代碼中嵌入中斷處理程序、驅動程序和物理 I/O 地址等不良實踐通常被認為是明智之舉，這些做法會加大移植到新硬件的難度。過去，一些極其糟糕的想法，比如編寫時序依賴型代碼，通常被認為更加明智。這種代碼可能需要重新編寫，才能在快速的現代硬件上運行。但即使存在匯編語言源代碼和不合時宜的編碼風格，我們仍然可以采用實際方法將傳統模塊整合到 FPGA 中。

第一種方法是，如果 CPU 的確非常老舊，則使用開源寄存器傳輸級 (RTL) 模型在 FPGA 中重新實施傳統微處理器或微控制器。Github 等資源擁有許多用于傳統處理器（包括 6502、Z80、6809、68000 和 8086）的 Verilog 模型。但在這些內核中進行設計之前，必須考慮幾個問題。

第一個問題是合法性。因為 Verilog 可用并不意味著您擁有在商業產品中使用該設計的合法權利。有一些模型是研究人員和業余愛好者編寫的，沒有考慮到知識產權。因此，很久之前的一些架構可能實際上位于公共域中。

另一個問題是作者的意圖。例如：Verilog 是架構的近似功能描述。它的目的是僅在模擬中執行代碼，還是封裝在用戶控件邏輯和 I/O 中？或者，該模型是否包含進入微處理器芯片的其他所有硬件？您必須匹配 Verilog 模型的特性和傳統系統的需求，否則將要花費大量的時間來了解舊芯片的劣勢。

接下來就是一些令人傷神的細節問題。SiFive 產品經理 Jack Kang 指出，與現代 CPU 一樣，傳統 CPU 也在整個產品生命周期中經歷了多次修改，每次修改都會糾正一些錯誤或劣勢。Verilog 代表哪個版本？或者它是一個理想化版本，代表著作者假定芯片怎樣正常運行的方式？最后是設計師的謹慎程度。該模型是否按照實際傳統芯片一個循環接一個循環地運行？是否啟動了您需要使用的操作系統？是否成功合成過？

如果 Verilog 模型無法正常運行，還有另一個選擇。老舊的 CPU 速度非常慢，以致于在當前 FPGA 中的微小現代 RISC 內核上運行的指令集模擬器都可以實時地遍歷傳統代碼，尤其是當麻煩序列卸載到 FPGA 中其他位置的狀態機上時。這種方法不能簡單地呈現周期精確或時序精確，但在功能上是正確的。而且它還可以將移植問題從硬件域轉換到軟件域，在軟件域，您可以訪問整個調試工作臺，這樣移植問題處理起來容易得多。

如何實施 CPU？

討論了將傳統代碼遷移至新系統的可行性和難度后，接下來的問題是如何在低端 FPGA 中實施 CPU 內核。我們之前討論過復制傳統 CPU 的情況，現在我們可以來了解下實施現代高性能 CPU 的選項。

主要問題是處理器內核依賴部分硬件結構，這種結構在 ASIC 中以標準單元甚至是自定義邏輯的形式實施，無法在 FPGA 結構中輕松高效地復制。因此，我們必須了解三種不同情況（圖 3）：

僅通過用于模擬或 ASIC 合成的 Verilog 模型進行合成的 CPU 內核 — 即所謂的開箱即用場景。

擁有面向 FPGA 合成手動優化的 RTL 的內核。

從一開始就開發了架構以在 FPGA 中實施的內核。每種方法的可用性、規模和性能都不相同。這些方法都適用于現代低端 FPGA。

圖3.CPU 內核中的三種 FPGA 優化級別。

開箱即用

盡管并不是每家 CPU 內核知識產權 (IP) 廠商都專門針對 FPGA，但大多數 IP 提供商都至少提供兩條遷移至 FPGA 內核的路徑。最明顯的路徑是授權面向內核的 RTL 源代碼，并通過 FPGA 廠商的工具鏈運行該代碼。實施這條路徑會遇到很多挑戰，全都是因為該 RTL 用于 ASIC 合成，而非 FPGA 合成。

特別是首次在 FPGA 中嘗試運行該代碼，那么遇到第一個問題將是：源代碼中的有些東西是采用 FPGA 合成工具無法處理的。代碼可能與合成工具不兼容的方式被隱藏或加密，可能包含您的工具無法識別的編譯指示、信號命名，甚至是帶有破壞性的注釋約定。您可以編輯這些內容，但會因此產生第二個問題：許可。

如果您使用用于 ASIC 開發的 Verilog 源代碼，可能需要進行編輯。這意味著您需要包含完整文檔的未隱藏的源代碼，以及/或 IP 廠商的大量支持。這些都是可用的，但它們都是針對財力雄厚、產量巨大、擁有大型法務部門的客戶所編寫和定價的。

還有另一條路徑：一些 IP 廠商提供評估或開發套件，您可以通過它們在 FPGA 中實施 CPU 內核。該內核可能沒有經過高度優化，但至少可以運行和驗證，而且其速度對軟件開發來說足夠快。

SiFive 產品經理 Jack Kang 表示，他的一些客戶已經采用了這種方法。該公司的 CoreDesigner 工具支持您從各種 RISC V 預配置內核開始，根據您特定的需求調整配置，然后輸出 RTL。但該工具也會在 SiFive 的開發套件上輸出一個關于 FPGA 的編程文件。

Kang 還指出，“RISC V 的這種 FPGA 實施并未面向 FPGA 使用進行高度優化，但仍然包含不到 20K 的查找表，而且速度可以達到 100 Mhz 左右，當然這很大程度上取決于配置。這種規模適合許多留有大量空間的低端 FPGA，支持您快速、輕松地將常用開源內核整合到系統中。”

優化方法

有一些方法可以改善這些數據，但需要采取一些措施。之所以有這種改善機會，是因為 CPU 中有一些結構并不適合 FPGA 邏輯結構。

FPGA 使用大量相同邏輯元件陣列來實施邏輯，每個元件都包含一些查找表 (LUT) — 通常每個 LUT 包含 4 個輸入 — 以合成邏輯函數，以及一個或多個觸發器。這種安排適用于大多數隨機邏輯、管道和簡單狀態機。對于高扇入邏輯，由于可能出現在算法硬件和地址解碼器中，因此合成往往會生成一長串窄邏輯元件，從而消耗互連并導致延遲。對于基于內存的功能，比如寄存器文件、高速緩存和相聯內存，一次將功能映射至邏輯元件的觸發器（一或二位）可能要消耗大量資源，即使廠商工具足夠智能，嘗試將邏輯元件的 LUT 和觸發器隔離，并單獨使用它們。

很久以前，當 FPGA 首次用于數據包切換、數字信號處理和類似應用時，這種不匹配就非常明顯。為了解決這個問題，FPGA 廠商在邏輯結構中嵌入了大型可分割 SRAM 模塊和硬件乘法累加模塊。通過使用這些資源，通常可以顯著改進 CPU 實施規模，有時還可以提高性能。但可能需要在 RTL 源代碼中或合成過程中運用一定的知識進行干預。如果熟練的 FPGA 用戶仔細檢查 RTL，并面向 FPGA 合成使用已知最佳 FPGA 編碼實踐對其進行調優，能夠進一步提升性能。

特定于FPGA的內核

行業標準 CPU 內核，比如 Cortex-M 家族或 RISC V，提供熟悉度、成熟的（或以 RISC 為例不斷壯大的）工具和軟件生態系統，以及在 FPGA 廠商之間輕松遷移或遷移至 ASIC 實施的機會，甚至在某些情況下還可遷移至第三方現成的 SoC。但反過來要付出一定的代價：費用、規模，有時還有性能。

如果您想最大限度地優化 FPGA，還需采取另一個步驟：不僅優化實施過程，還要優化 CPC 和指令集架構本身：從一張白紙開始，僅添加對 FPGA 友好的結構。很久以前，當 FPGA 首次變得足夠大，可容納 CPU 內核時，主要 FPGA 廠商就已經開始做出這樣的努力。他們始終在做出這樣的努力：在英特爾案例中為 Nios II 處理器，其以發展演進為專有 CPU 架構，不斷壯大由工具、軟件和 FPGA 外設 IP 組成的生態系統。

目前，這些內核家族提供多種類型的產品，從具備最少特性的小型微內核 （和 Arm 的 Cortex M0 沒什么不同）到全功能、支持 Linux 的 CPU。其中許多型號都適用于廠商的低端 FPGA。例如，緊湊型 Nios Iie 內核只需大約 1000 個邏輯元件，但速度可達到或超過 75 MHz。在另一個極端，具備高速緩存和內存管理功能，且能夠運行 Linux* 操作系統的內核大約需要 5000 個元件。在這兩者之間還有許多選擇來滿足特定需求。甚至這種全功能配置也足夠小，不但可以將多核 CPU 集群放在一臺低端英特爾 MAX 10 設備中，還仍然擁有足夠的空間。

因此，有許多方法可以將傳統 CPU 功能遷移至低端 FPGA，同時仍然擁有豐富的資源來支持傳統接口或控制器功能、IoT 連接、安全性，或機器學習加速。古老的機器代碼可在 FPGA 上運行，以向老舊 CPU 致敬，也可在現代內核的指令集模擬器上運行。

高級語言代碼可面向現代代碼進行編譯。極具挑戰性的代碼模塊可以卸載到 FPGA 中的加速塊中，然后通過多種優化程度各不相同的方法，得到許可并在 FPGA 中實施現代 CPU 內核的某個版本。為了最大限度地提高資源效率，廠商專有 CPU 內核可在各種性能和功能點中實現最佳的緊湊性，且幾乎適合所有的設計場景。

審核編輯：湯梓紅