軟件定義芯片(下冊)（簡體書）

目錄
上冊
序
前言
第1章 緒論 1
1.1 概念演變 2
1.1.1 半導體積體電路發展背景 4
1.1.2 計算晶片體系架構發展背景 5
1.1.3 軟件定義晶片VS.可程序設計器件 7
1.1.4 軟件定義晶片VS.動態可重構計算 7
1.2 可程序設計器件發展 10
1.2.1 歷史發展分析 10
1.2.2 FPGA的技術原理 11
1.2.3 FPGA發展面臨的問題 14
1.2.4 軟件定義晶片的顛覆性 16
1.3 國內外研究與產業現狀 17
1.3.1 經典可程序設計器件的發展現狀和趨勢 17
1.3.2 軟件定義晶片的研究現狀 18
參考文獻 20
第2章 軟件定義晶片概述 24
2.1 基本原理 25
2.1.1 必要性分析 25
2.1.2 技術實現方法 28
2.1.3 技術對比 45
2.2 特性分析 51
2.2.1 高計算效率 51
2.2.2 程序設計門檻低 56
2.2.3 容量不受限 57
2.2.4 高硬體安全 57
2.3 關鍵研究問題 59
2.3.1 程序設計模型與靈活性 62
2.3.2 硬體架構與高效性 63
2.3.3 編譯方法與易用性 64
參考文獻 65
第3章 硬體架構與電路 69
3.1 軟件定義架構的設計原語 70
3.1.1 計算和控制 70
3.1.2 片上存儲 96
3.1.3 對外接口 105
3.1.4 片上互連 111
3.1.5 配置系統 117
3.1.6 小結 121
3.2 軟件定義架構的開發框架 122
3.2.1 架構設計空間探索 123
3.2.2 敏捷硬體開發實例 134
3.2.3 小結 148
3.3 軟件定義電路的設計空間 148
3.3.1 可調電路探索 149
3.3.2 模擬計算探索 152
3.3.3 近似計算探索 157
3.3.4 概率計算探索 165
3.3.5 小結 166
參考文獻 166
第4章 編譯系統 174
4.1 編譯系統概述 175
4.1.1 靜態編譯流程 175
4.1.2 動態編譯流程 178
4.2 靜態編譯方法 179
4.2.1 中間表達形式 179
4.2.2 映射問題抽象與建模 186
4.2.3 軟件流水與模調度 192
4.2.4 整數線性規劃 212
4.2.5 非規則的任務映射 223
4.3 動態編譯方法 241
4.3.1 硬體資源虛擬化 242
4.3.2 基於指令流的動態編譯 248
4.3.3 基於配置流的動態編譯 257
參考文獻 270
彩圖
下冊
序
前言
第1章 程序設計模型 1
1.1 軟件定義晶片的程序設計模型困境 2
1.2 三條路線 3
1.3 三大障礙 5
1.3.1 馮 諾依曼架構與隨機存取機模型 6
1.3.2 內存牆 8
1.3.3 功耗牆 12
1.3.4 I/O牆 21
1.4 三元悖論 24
1.5 三類探索 27
1.5.1 空域並行性與非規則應用 27
1.5.2 空域並行性的程序設計模型 31
1.6 本章小結與展望 60
參考文獻 62
第2章 硬體安全性和可靠性 65
2.1 安全性 66
2.1.1 故障攻擊防禦技術 66
2.1.2 抗側通道攻擊防禦技術 70
2.1.3 基於軟件定義晶片的PUF 技術 79
2.2 可靠性 89
2.2.1 基於*大流算法的拓撲結構重構方法 90
2.2.2 可重構片上網絡多目標聯合映射優化方法 99
參考文獻 115
第3章 技術難點與發展趨勢 120
3.1 技術難點分析 120
3.1.1 靈活性：軟硬體協同的可程序設計性設計 121
3.1.2 高效性：硬體並行性和利用率的權衡 123
3.1.3 易用性：軟件調度的虛擬化硬體優化 127
3.2 發展趨勢展望 129
3.2.1 應用驅動的軟硬體一體化設計 129
3.2.2 存算融合的多層次並行化設計 132
3.2.3 軟件透明的硬體動態優化設計 139
參考文獻 142
第4章 當前應用領域 148
4.1 應用領域分析 148
4.2 人工智能 151
4.2.1 算法分析 151
4.2.2 人工智能晶片研究現狀 154
4.2.3 軟件定義人工智能晶片 165
4.3 5G通信基帶 173
4.3.1 算法分析 173
4.3.2 通信基帶晶片研究現狀 178
4.3.3 軟件定義通信基帶晶片 184
4.4 密碼計算 191
4.4.1 密碼算法分析 192
4.4.2 密碼晶片研究現狀 197
4.4.3 軟件定義密碼晶片 201
4.5 處理器硬體安全 207
4.5.1 概念及研究現狀 207
4.5.2 CPU硬體安全威脅分析 207
4.5.3 現有應對方案 209
4.5.4 基於軟件定義晶片的CPU 硬體安全技術 210
4.6 圖計算 217
4.6.1 圖算法的背景介紹 218
4.6.2 圖計算的程序設計模型 222
4.6.3 圖計算硬體架構研究進展 226
4.6.4 展望 238
4.7 網絡通訊協定 239
4.7.1 軟件定義網絡通訊協定 240
4.7.2 軟件定義網絡晶片研究現狀 245
4.7.3 軟件定義網絡晶片技術 255
參考文獻 259
第5章 未來應用前景 268
5.1 可演化智能計算 269
5.1.1 可演化智能計算的概念與應用 269
5.1.2 可演化智能計算的歷史與現狀 270
5.1.3 軟件定義可演化智能計算晶片 274
5.2 後量子密碼 275
5.2.1 後量子密碼算法的概念與應用 276
5.2.2 後量子密碼晶片研究現狀 280
5.2.3 軟件定義後量子密碼晶片 284
5.3 全同態加密 285
5.3.1 全同態加密的概念與應用 286
5.3.2 全同態加密晶片研究現狀 288
5.3.3 軟件定義全同態加密計算晶片 290
參考文獻 297
彩圖

第1章 程序設計模型
All problems in computer science can be solved by another level of indirection， except for the problem of too many layers of indirection.
計算機科學中幾乎所有的難題都可以通過增加中間層解決，但計算機科學的難題在於已經有了太多中間層。—— David Wheeler[1]
軟件定義晶片與 ASIC的*大區別在於，軟件定義晶片需要像通用處理器那樣執行使用者編寫的軟件。 ASIC僅針對特定應用，它只需提供專用的 API，無須考慮程序員如何對其進行程序設計的問題。而軟件定義晶片的功能，*終是靠程序員來實現的。一套硬體能吸引大量使用者投入精力開發軟件的一個必要條件是硬體上的軟件是向前相容的：即使新一代的硬體設計發生了翻天覆地的變化，之前使用者編寫的軟件依然可以在新的晶片上正確運行。軟件與硬體間進行對話的“語言”即程序設計模型。
廣義的程序設計模型是指從應用到晶片之間的所有抽象層次。通用處理器晶片在漫長的發展過程中，逐漸形成了由程序設計語言、編譯器中間表示、指令集架構等抽象層次構成的複雜的層次化中間層(indirection)模型。在這些模型中，上層中間層依次掩藏下層中間層的複雜性。例如，為了掩藏指令集架構層指令計數器可以任意跳轉(如 x86指令集中的 jump類指令)所帶來的複雜流程控制，程序設計語言層提供了多種流程控制語句，如 C語言中的語句。這樣程序員在開發應用時，只需要面向特定中間層開發應用，而無須考慮底層實現的複雜性。
然而，作為一種與通用處理器和 ASIC在晶片架構和程序設計模型設計上都不同的新興計算架構，軟件定義晶片的程序設計模型面臨著“先有雞還是先有蛋”的困境：沒有軟件定義晶片的程序設計模型，軟件定義晶片的晶片設計如“無源之水”，缺少指引晶片設計方向的軟件；沒有軟件定義晶片的晶片設計，軟件定義晶片的程序設計模型設計如“無本之木”，缺少檢驗程序設計模型有效性的硬體。
為了破解這個僵局，本章將回溯現代通用處理器體系結構和程序設計模型協同演化的歷程。1.1節詳細分析僵局的成因和影響。1.2節考察現代程序設計模型的中間層結構，然後從中歸納出三種程序設計模型的設計路線。1.3節考察晶片設計和程序設計模型應當如何應對半導體器件工藝發展不平衡帶來的“三堵高牆”，即“內存牆”、“功耗牆”和“I/O牆”。越來越複雜的硬體催生了五花八門的程序設計模型。1.4節將從程序設計模型的演化歷程總結“程序設計模型三元悖論”：新的程序設計模型無法同時獲得高通用性、高開發效率和高執行效率，*多只能同時實現兩個目標，而放棄另一個目標。結合計算系統抽象層次對硬體複雜性的處理方法，可以經驗性地說明三元悖論的合理性。*後，1.5節基於“三元悖論”，針對軟件定義晶片的程序設計模型困境提出三個可能的研究方向。
1.1 軟件定義晶片的程序設計模型困境
在過去60年裡，人類創造了一個指數增長的奇觀：晶片性能持續指數增長，晶片之上的應用愈發複雜多樣。程序設計模型作為晶片與應用之間的契約，借由契約的前後一致性，確保了過去的應用可以方便地移植到未來的晶片上。但摩爾定律的終結，如釜底抽薪，破壞了計算產業的奇觀。對於軟件定義晶片，必須將晶片設計從舊的契約中解放出來，重新思考晶片、程序設計模型和應用的關係。
沒有軟件定義晶片程序設計模型，軟件定義晶片的體系結構設計如“無源之水”，缺少指引硬體設計方向的軟件。體系結構研究中，對硬體範式轉換*直接的應對方法是發明一種新的(領域定制)程序設計模型。儘管新程序設計模型在短期內很有吸引力，但這通常意味著程序員必須重新編寫代碼，並且會給軟件發展團隊帶來嚴重的理解、交流障礙，令學習曲線變得陡峭。而在硬體架構快速反覆運算的階段，直接花費大量人力物力，針對不斷演化的體系結構設計開發自動化的編譯器也不現實。這導致在設計新硬體範式時，目標應用難以對硬體設計中的決策進行快速響應，因而通常面臨無軟件可用的困境。
沒有軟件定義晶片體系結構，軟件定義晶片的程序設計模型設計如“無本之木”，缺少給程序設計模型開發提供著力點的硬體。程序設計模型的作用是掩藏複雜的硬體機制。在摩爾定律對增強通用處理器性能還有效的時代，程序設計模型的設計遠比今天簡單。雖然處理器的硬體機制可能在代際之間發生巨變，但是新一代處理器的指令集架構(instruction set architecture，ISA)只需要增加少數幾條或幾類指令。因此，上一代的程序設計模型、編譯器和程序設計語言只需要做少許改動便可應用在新一代處理器上。然而，隨著摩爾定律在增強處理器性能方向上的失效，定制化成為新一代硬體*重要的性能來源。這些定制化硬體很難用一套統一的或者類似的 ISA進行抽象。所以，不同的新硬體都需要不同的程序設計模型。在新興硬體範式還沒有定型之時，程序設計模型難以明確到底要掩藏哪些硬體機制。
如果無法解決這個“先有雞或者先有蛋”的悖論，軟件定義晶片的發展將會面臨兩種結局，即要麼由軟件無法適應而導致硬體發展停滯，要麼軟件無法利用硬體進行創新。為了打破這種僵局，需要從根本上重新思考如何設計、程序設計和使用軟件定義晶片。
我們相信，通過回溯現代通用處理器體系結構和程序設計模型協同演化的歷程，對歷史經驗進行反思和概念探討，可以克服常識的零散和碎片化，進而更為連貫一致地理解軟件定義晶片程序設計模型的設計方法。
1.2 三條路線
正如本章引言所述，中間層是計算行業增長和生產力進步的主要驅動力。如今大多數計算機專業從業者可能都不知道現代微處理器的工作原理和半導體制程的工藝流程。但是通過維護這些層層相扣的中間層，計算機專業從業者可以在更高的抽象層次，如使用 Python，高效率地進行編碼工作。由此才使得今天的應用得以百花齊放。
圖1-1展示了當代計算行業中，自頂(應用)向下(晶片)的典型中間層。按照傳統的軟硬體劃分方法，自 ISA以上是軟件， ISA以下是硬體。越靠上的中間層抽象層次越高，程式的開發效率越高；越靠下的中間層複雜度越高，程式的執行效率越高。引入新的中間層的目的，就是要掩藏其下方中間層的複雜性，從而提高開發效率。
圖1-1 計算機科學中自頂(應用)向下(晶片)的典型中間層示意
如果說整個計算行業琳瑯滿目的應用像是鱗次櫛比的高樓大廈，那麼每一個中間層就是一層樓，程序設計模型就是黏合這些瓊臺玉宇的水泥。狹義的程序設計模型是指從應用層到微架構層中，層與層之間的契約。具體而言，程序設計模型規定了上層的哪些行為合法，以及每個行為在下一層的執行機制。微架構層到實體層中同樣存在類似的契約，如寄存器傳輸層到器件層之間使用網表檔作為契約。由於應用開發者不會與這些契約打交道，因此它們不屬於本章討論的程序設計模型範疇。
但是，正如本章引言的後半句所言，過多的中間層是一個難以解決的問題。這裡的一個關鍵問題在於，每一個中間層的引入都會對應用在晶片上的性能造成損失。中間層越多，性能損失越大。因此，抽象層次極高的程序設計語言，如 Python、JavaScript等，主要的設計目標都是提高開發效率和擴大應用範圍。為了達到這兩個目標，高抽象層次語言具有許多共同的特徵，例如，通常被單執行緒地解釋，以及具有基於引用計數等簡單算法的垃圾回收機制等。因為這些特徵，高抽象層次語言的執行效率極為低下。2020年《科學》雜誌刊登了一篇計算機體系結構的論文《頂部還有足夠的空間》[2]，其中的一個例子表明，使用 Python編寫的矩陣乘法程式的執行時間是同等水準開發者使用高度優化的 C語言編寫的程式執行時間的100～60000倍，如表1-1所示。不僅如此，高抽象層次語言執行時也需要更大的內存。例如， Python中的整數佔用的是24個位元組，而不是 C語言的4個位元組(因為每個物件都攜帶類型信息、引用計數等)，而清單或字典等資料結構的內存開銷則是 C++開銷的4倍以上。當然，這些高抽象層次語言的設計目標並不是高效地利用硬體。但當晶片的性能不再隨著摩爾定律的前進而增長時，高抽象層次語言和高性能語言之間的執行效率差距就成為尚未充分發掘的金礦。
表1-1 不同程式執行4096×4096矩陣乘法運算的加速對比[2]
注：每個版本代表了一種對 Python源碼的連續改進。執行時間是該版本的執行時間。 GFLOPS是該版本每秒執行64位浮點操作的次數(單位為十億)。絕對加速是相對 Python的速度，而在展示中有附加精度位元數的相對加速則是相比前一版本的加速。峰值占比是相比於計算機的835 GFLOPS的占比。
根據開發過程中開發者主要使用哪個中間層，將計算產業的從業者大致分為四種類型(圖1-1)：硬體開發者，負責設計電路和製造晶片，主要在電路的層次設計 ALU、快取內存等模組；架構設計師，負責設計微架構 ISA，利用硬體開發者設計的模組搭建計算系統，並將計算系統的功能以 ISA或者 API的形式提供給上層開發者；編譯設計師，根據應用需求和架構特性，負責設計程序設計語言和編譯工具鏈，從而可以將應用開發者編寫的應用自動地轉化為目標架構可以執行的機器碼；應用開發者，使用程序設計語言開發應用。參照前面的定義，程序設計模型可以看成應用開發者與硬體開發者進行對話的語言，該語言由架構設計師和編譯設計師設計。
考慮到負責掩藏複雜硬體機制從業者類型的不同，可以簡要地歸納出三種程序設計模型的設計路線。首先，有些硬體機制只需要交給架構設計師考慮，一般不需要編譯器的幹預。例如，當今流行的領域定制加速單元，通常都是由架構設計師提供一組簡單的 API或者專用指令，供上層的編譯器和應用開發者直接調用。其次，有些硬體機制可以交由編譯設計師處理，而不需要讓應用開發者瞭解。例如， CPU中成百上千個寄存器，都可以由編譯器自動完成分配。*後，很多硬體機制的性能潛力，必須由應用開發者根據應用的需求編寫程式才能被充分開發。例如，多執行緒處理器的併發執行機制需要應用開發者使用並行程序設計語言編寫程式才能被充分利用。
三種設計路線給程序設計模型帶來截然不同的特徵。程序設計模型的發展歷程就是這三條路線相互角力達到平衡的過程。下面將按照時間順序回溯典型硬體機制的設計動機和程序設計方法。
1.3 三大障礙
Gene Amdahl因“Amdahl定律”[3]而舉世聞名。這個定律指出，平行計算性能隨著執行緒數的增加，邊際收益遞減。但 Amdahl於1967年同時提出了第二條原則[3]，稱為“ Amdahl經驗法則”或“ Amdahl的另一條定律”：硬體架構設計需要平衡算力、內存頻寬和 I/O頻寬，理想的處理器計算性能、內存頻寬與 I/O頻寬的比例為1∶1∶1，即每秒百萬條指令數(million instructions per second，MIPS)的處理器計算性能需要1MB的內存和1 Mbit/s的 I/O頻寬。
圖1-2 1980～2020年 CPU計算性能、內存頻寬、磁片頻寬和網絡頻寬隨時間的變化(當硬體性能錯位的張力無法在之前的體系結構-程序設計模型的設計中得以解決時，計算系統遇到了“內存牆”、“功耗牆”和“ I/O牆”[4])(見彩圖)
“Amdahl經驗法則”在提出時曾被作為金科玉律，但時至今日已鮮為人知。其原因在於，自1985年，由於積體電路工藝的發展，計算系統的內存頻寬與 I/O頻寬的比例，無法與計算性能維持在1∶1∶1的理想比例。如圖1-2所示，在不同的時間段， CPU計算性能、內存頻寬、磁片頻寬和網絡頻寬的增速各有不同。如同地殼運動中兩個板塊間的錯位會形成懸崖峭壁，計算系統中不同模組的性能錯位也會形成一堵堵“高牆”。積體電路誕生60年後的今天，產業界和學術界公認三堵“高牆”分別為：1995年後內存性能和 CPU性能錯位形成的“內存牆”(memory wall)、2005年後 CPU性能和晶片功耗錯位形成的“功耗牆”(power wall)和2015年後 CPU性能和 I/O頻寬錯