異構(gòu)計(jì)算的軟硬件分割沒有最好，只有更好的詳細(xì)資料概述

我們有飛機(jī)、汽車、輪船、自行車、地鐵、高鐵、公交車、雙腿等各種交通工具，各自有優(yōu)缺點(diǎn)，舉個(gè)例子，阿呆從上海出差去北京賣書，整個(gè)流程是：

1. 打車到虹橋高鐵站：靈活機(jī)動(dòng)，運(yùn)量小，24小時(shí)運(yùn)營(yíng)，經(jīng)常堵車；

2. 坐高鐵到北京南站：高速，運(yùn)量大，路線、時(shí)間和起始站點(diǎn)有限制，建設(shè)周期長(zhǎng)；

3. 從北京南站坐地鐵到奧林匹克公園地鐵站：市內(nèi)速度穩(wěn)定，運(yùn)量大，時(shí)間和起始站點(diǎn)有限制，建設(shè)周期長(zhǎng)；

4. 從地鐵站走路到國(guó)家會(huì)議中心新書簽售：慢，但是方便，兩條腿，沒有路都能走出一條路。

可以看出，一次旅行，其實(shí)結(jié)合了各種交通工具的優(yōu)點(diǎn)。隨著摩爾定律的失效和CPU在AI等并行計(jì)算方面的缺陷，目前數(shù)據(jù)中心的計(jì)算機(jī)，已經(jīng)不僅僅是CPU一種計(jì)算芯片，還要結(jié)合GPU和FPGA做異構(gòu)計(jì)算體系。

CPU是出租車，方便靈活，但是要等紅綠燈，市區(qū)內(nèi)道路多，有限速，運(yùn)量小，車多了還堵車；FPGA是高鐵和地鐵，運(yùn)量大，但是建設(shè)周期長(zhǎng)，只能部署在人流量最大的線路上。

我們做異構(gòu)計(jì)算的軟硬件分割也是遵循同樣的思想，普通的控制程序還是交給CPU執(zhí)行，把計(jì)算量最大、最耗時(shí)間的任務(wù)轉(zhuǎn)移到FPGA上執(zhí)行，達(dá)到硬件加速的目標(biāo)。

軟硬件最佳分割方案：理論上無解

如下圖，一個(gè)程序，通過對(duì)程序進(jìn)行分割，把任務(wù)分解到CPU和FPGA、GPU、AI芯片等加速器執(zhí)行。如果我們把程序分成N段，那么每一段都有兩個(gè)選擇：軟件或者硬件，最后N段程序有2^N種分割方案，所以，最終要分段程序，尋找分配到軟硬件的最佳方案是一個(gè)數(shù)學(xué)上有名的NP難題，解不出來。。。

我們沒辦法算出一個(gè)理論上的最佳方案，只能是不斷逼近，沒有最好，只有更好。

我們希望有一天能做到像下面這張圖一樣，我們寫好的C/C++/Java等代碼，編譯后，自動(dòng)分解成軟硬件執(zhí)行的程序，軟件的交給CPU執(zhí)行，硬件的讓FPGA執(zhí)行。盡管很難，但是還是要有夢(mèng)想，萬一實(shí)現(xiàn)了呢？

阿姆達(dá)爾定律

現(xiàn)在有很大一批人，對(duì)新的產(chǎn)品和技術(shù)比較排斥，覺得很low，沒有技術(shù)含量?？墒?，任何一個(gè)新東西，剛出來的時(shí)候就是很簡(jiǎn)單，慢慢才變得復(fù)雜。比如區(qū)塊鏈、深度學(xué)習(xí)、量子通信這些熱門的技術(shù)，一開始實(shí)踐的時(shí)候并不是很復(fù)雜。

1967年，有一位IBM的計(jì)算機(jī)科學(xué)家叫做阿姆達(dá)爾（Amdahl），他寫了一個(gè)很簡(jiǎn)單的公式，卻成了并行計(jì)算領(lǐng)域的基本定律。阿姆達(dá)爾定律說，一個(gè)程序能被硬件加速多少倍，其實(shí)取決于不能被硬件加速的那段程序。比如四分之三的程序可以通過并行計(jì)算、流水線等技術(shù)被硬件加速，但是有四分之一的程序還是得順序執(zhí)行，那么加速最大的倍數(shù)就是四分之三的程序幾乎不花時(shí)間就算完了，用了四分之一的時(shí)間執(zhí)行剩下不能加速的程序，最終可以加速4倍。

我們也知道這叫短板效應(yīng)，木桶的容積是最短的那塊板決定的。我們中國(guó)現(xiàn)在高鐵、電視、冰箱、移動(dòng)支付、共享單車、輪船都能做到世界第一，但就是芯片不能造，導(dǎo)致國(guó)家還是受制于人（美帝）。

當(dāng)然，這個(gè)程序的占比不是按照代碼的長(zhǎng)短算的，而是按照程序執(zhí)行的時(shí)間劃分。為了達(dá)到最好的硬件加速效果，我們要把最占時(shí)間的程序都放到FPGA去。

關(guān)于這個(gè)定律的詳細(xì)解釋請(qǐng)參考科大陳國(guó)良院士的《并行計(jì)算機(jī)體系結(jié)構(gòu)》一書2.3.1節(jié)。

90%/10%定律

上面這張圖是對(duì)一個(gè)程序中執(zhí)行最多的的10段代碼占用時(shí)間的累計(jì)，符合90%/10%定律：10%的代碼執(zhí)行占用了90%的程序運(yùn)行時(shí)間。

所以我們很幸運(yùn)，不需要操心那么多軟件代碼，只需要把最關(guān)鍵的10%代碼轉(zhuǎn)移到FPGA就可以了。

軟硬分割的考慮因素

我們?cè)趯?duì)一個(gè)程序做軟硬分割時(shí)，需要回答以下幾個(gè)問題：

1. 程序分段粒度多大？

2. 分割方案的評(píng)估

3. 每段分區(qū)有哪些實(shí)現(xiàn)方案？

4. 軟硬件如何交互？

5. 計(jì)算占用的面積。

程序分段粒度多大？

其實(shí)就是要把程序里的哪幾段代碼下放到硬件去，開小灶。這個(gè)代碼段要分到多細(xì)？如果太粗，那么操作比較簡(jiǎn)單，花的時(shí)間少，但是最終效果可能沒那么好。分的太細(xì)，又太花時(shí)間，每一段都要分析和推算，考慮軟硬件交互，甚至需要專門的工具去做。

最簡(jiǎn)單的辦法就是挑幾個(gè)關(guān)鍵的函數(shù)、算法或者for/while循環(huán)放到硬件去加速。

分割方案的評(píng)估

如果我們要確定軟件和硬件分工的方案，就需要評(píng)估和對(duì)比幾個(gè)方案，從性能、成本、功耗等幾個(gè)方面來評(píng)價(jià)。項(xiàng)目一開始，其實(shí)做不了太精確的評(píng)估，只能是粗糙的做一個(gè)估算，看看到底要用到多少LUT、RAM和乘法器、硬件IP等資源，再估算性能和延遲。

等到大體確定了一個(gè)目標(biāo)方案，就可以寫代碼，用綜合工具做一個(gè)綜合，就能得到比較精確的資源占用情況。

不同的實(shí)現(xiàn)方案怎么選擇？

對(duì)于每一段要硬件加速的軟件程序，硬件上都有不同的實(shí)現(xiàn)方案。如下圖，是100個(gè)乘法的例子，有三個(gè)方案：

(a)方案用了100個(gè)乘法器，性能最強(qiáng)，用的資源也最多；

(b)方案用了1個(gè)乘法器，要排隊(duì)乘100次才能算完，性能最差，用的資源最少；

(c)方案用了10個(gè)乘法器，每個(gè)用10次，性能和資源都比較折中。

所以，最終采用什么方案要根據(jù)實(shí)際的需求和FPGA的大小來確定，F(xiàn)PGA不是ASIC，資源沒有那么多，能省則省。

軟硬件如何交互？

本來是一個(gè)順序執(zhí)行的軟件程序，我們拆出了一部分放到FPGA去執(zhí)行，所以就涉及到軟硬件交互的問題。如下圖(a)，

左邊是同步方案，軟件干完，就讓FPGA干，軟件在旁邊等，這樣交替干活。這種方案比較傻瓜式，簡(jiǎn)單易行。而且性能不一定差，因?yàn)橛布?jì)算快，軟件可能等一會(huì)兒就好了。

右邊是異步方案，軟件和硬件各干各的，同時(shí)工作，效率高，但是控制比較復(fù)雜，畢竟涉及到一些共享的數(shù)據(jù)，處理起來比較麻煩。如果硬件計(jì)算時(shí)間長(zhǎng)，軟件等得久，就可以考慮這種模式。

另外，還要考慮軟硬件的通信方式，如上圖(b)，是各種通信方案，有的通過共享內(nèi)存，有的是通過CPU直連、共享緩存，還有像牛郎織女一樣搭一座橋互聯(lián)。還有幾個(gè)硬件加速器之間綁定在一起和CPU通信，還是分開，都需要考慮到。

用AI輔助軟硬件劃分

傳統(tǒng)的硬件加速項(xiàng)目流程如下：

1. 確定要加速的軟件程序；

2. 架構(gòu)師通過評(píng)估和統(tǒng)計(jì)數(shù)據(jù)、性能計(jì)算確定軟硬件分離方案和硬件架構(gòu)；

3. 工程師開始寫代碼、仿真、驗(yàn)證、測(cè)試。

但是，也有一些自動(dòng)化工具來智能評(píng)估軟硬件分割方案。前面說過，理論上是找不到最佳方案的，因?yàn)橛?jì)算量是個(gè)天文數(shù)字，我們只能不斷逼近。逼近的方法如下：

1. 把程序切分成幾段，給出軟件和硬件時(shí)間、硬件資源，算出一個(gè)評(píng)估結(jié)果。

2. 再隨機(jī)把程序分段，算出一個(gè)評(píng)估結(jié)果，看看是不是更好，如果更好，就用這個(gè)方案。

3. 繼續(xù)迭代。

上面的方法采用了隨機(jī)數(shù)的方法，不斷找到更優(yōu)解。但是，如今隨著AI的日漸成熟，我們相信，也會(huì)有人會(huì)用AI技術(shù)來尋找更好的自動(dòng)化軟硬件分離方案。