叢京生院士介紹了他在民主化集成電路設(shè)計和可定制計算上的由一系列工作所形成的生態(tài)系統(tǒng)。作者 | VASTLab
引言：叢京生院士為作者之一的論文“AutoDSE: Enabling software programmers to design efficient FPGA accelerators”獲得了2023 ACM TODAES最佳論文獎。為了介紹這項工作以及叢院士在民主化集成電路設(shè)計和可定制計算上所構(gòu)建的生態(tài)系統(tǒng)，VLSI架構(gòu)綜合技術(shù)研究室翻譯了他在ICCAD’2022開幕日所做的主題演講，以饗讀者。
叢京生院士報告全文如下：很高興在ICCAD’2022現(xiàn)場見到這么多同仁！我本人也非常榮幸能夠在這次的ICCAD開幕日做主題演講。ICCAD對我來說有著非常特別和重要的意義。35年前我的第一篇論文是在ICCAD上發(fā)表的。在這張幻燈片左邊，你可以看見這篇文章的截圖。因為年代久遠(yuǎn)，我并沒有在ICCAD Proceedings上找到這篇文章的電子版，但是我在IEEE Transactions on CAD上還是找到了這篇文章的期刊版本。
幻燈片右邊，你能看見當(dāng)年UIUC四位年輕的研究生。站在我旁邊的男士是黃定發(fā)教授，他現(xiàn)在是香港中文大學(xué)工程學(xué)院院長。站在我旁邊的年輕女士現(xiàn)在是IBM EDA部門的資深員工。站在照片最左邊的男士是KC Chen。你們中的有些人可能知道他是前世界級芯片驗證公司Veriplex的共同創(chuàng)辦人。Veriplex后來被Cadence收購。當(dāng)我找到這張照片的時候，心中涌起了許多回憶。最重要的一點，我想說這次的主題演講也是為我的導(dǎo)師劉炯朗先生所做。他也是這篇文章的作者之一。他的一言一行帶領(lǐng)我走進(jìn)了EDA的世界并引導(dǎo)我了解如何真正做好科研。我非常希望劉炯朗先生今天也能在現(xiàn)場，然而他在兩年前不幸過世。相信我們所有人都會記住他在這個領(lǐng)域深耕幾十年的巨大貢獻(xiàn)。
01.15年前轉(zhuǎn)變賽道讓可定制計算成為可能
我在這篇文章里講的是一種三層芯片設(shè)計通道布線（three-layer channel routing）的方法。這在當(dāng)時是個新問題，是我在1987年根據(jù)當(dāng)年的技術(shù)水平寫的文章。在那個時候芯片還只有兩層的設(shè)計所以我們猜測工業(yè)界會向三層或者多層發(fā)展。那么這個情況下的布局布線問題就是個很好的研究課題。實際上，我們在兩年后的確看見Intel在486處理器上使用了三層的設(shè)計，順帶一提486芯片同時實現(xiàn)了片內(nèi)集成超一百萬晶體管的這個令人激動的里程碑。
所以當(dāng)回看這35年間我的實驗室的科研路線，前20年，我的關(guān)注點一直在服務(wù)于硬件工程師的電子設(shè)計自動化。我們希望他們可以設(shè)計出更好的奔騰處理器或者更好的硬件加速器。但是過去的10年或15年我們逐漸地改變了重心：變成可以讓更多的軟件工程師來設(shè)計他們自己所需要的定制化集成電路和加速器，特別是其在FPGA上的實現(xiàn)。當(dāng)被問到為什么我們要轉(zhuǎn)換跑道，我想說，我們想使得可定制計算成為可能。我們可以用下面這幅圖來解釋一下15年前為什么我們決定開始轉(zhuǎn)變賽道。
各位可能都見過這幅Intel繪制的能耗圖線。我們可以看到頻率的增加是和熱量的產(chǎn)生成正比的。今天大多數(shù)的芯片都運(yùn)行在2-4GHz之間。想做一個太赫茲級的芯片其實是沒有問題的，只是做完運(yùn)行后你大概率會發(fā)現(xiàn)芯片被自己燒了。所以工業(yè)界在2000年中后期沿著圖線向右折了一下， 從單純提高頻率轉(zhuǎn)向并行設(shè)計?；疽馑季褪俏覀儽M量保持現(xiàn)有的頻率，然后增加更多的核來設(shè)計出更強(qiáng)大的芯片。當(dāng)時也有對功率和散熱進(jìn)行專門的分析。在那個時候，我們實際上已經(jīng)提出了一個更大膽的想法，那就是我們應(yīng)該再往下走一步讓芯片架構(gòu)服務(wù)于具體應(yīng)用，而不是先固定架構(gòu)再進(jìn)行開發(fā)。所以我們向美國國家科學(xué)基金會（NSF）提交了一個相關(guān)的項目申請。很幸運(yùn)，這個項目獲得了NSF的5年1000萬美元的資助并同時獲得了Expedition in Computing的獎項。這在當(dāng)時應(yīng)該是NSF最大的獎項和資助之一。在申請中我們寫了出現(xiàn)在幻燈片里的一句話“不止著眼于并行設(shè)計，同時關(guān)注特定領(lǐng)域可定制設(shè)計從而顯著提高功耗-性能的效率”。我們不僅寫下了這句話，我們也是沿著這個方向努力去做的。實際上也有很多同仁做出了成功的例子。其中最著名的例子是谷歌的TPU。TPU就是專門為一種應(yīng)用而設(shè)計的，那就是深度學(xué)習(xí)。如果你仔細(xì)去看TPU的設(shè)計架構(gòu)，他主要就是由一個個矩陣-向量乘法塊或者矩陣-矩陣乘法塊構(gòu)成。TPU的論文報告了相比于最先進(jìn)CPU快200倍，GPU快70倍的性能提升。當(dāng)然現(xiàn)在CPU和GPU的性能也在提升，所以這是個大概的數(shù)字。谷歌的TPU是個非常大的成就。但是設(shè)計類似TPU這樣的特定芯片有一些顯著的限制。首當(dāng)其沖的問題就是必須非常有錢。根據(jù)麥肯錫做的調(diào)查報告設(shè)計制造7nm的芯片需要花費(fèi)至少15億人民幣。你有沒有15億人民幣這是第一個問題。第二個問題是你必須要很有耐心。我實驗室的學(xué)生不是很喜歡去設(shè)計芯片以及流片，原因之一就是從你有想法到流片成功至少需要兩年的時間。萬一你的設(shè)計流片回來發(fā)現(xiàn)有問題你又要重新流片，這就很難及時發(fā)出文章。一般畢業(yè)你可能需要有三篇文章發(fā)表，那你什么時候才能畢業(yè)呢？不僅如此各類算法和設(shè)計都在快速推陳出新，可能現(xiàn)在的想法很快就過時了。所以冗長的設(shè)計周期也是一項限制。盡管可定制計算芯片有諸多限制，你還是可以在可編程邏輯器件FPGA上實現(xiàn)很多的可定制計算，也能達(dá)到很高的計算效率。我在這里想舉一個我們在ISCA’2020上發(fā)表的工作。這項工作其實是在講一個很經(jīng)典的問題——排序。不過不是對10000個數(shù)字排序，而是對超大規(guī)模，比如10T規(guī)模的數(shù)字進(jìn)行排序。我們的做法從宏觀上看是一個簡單的歸并排序，這樣的排序先對許多小塊數(shù)據(jù)進(jìn)行排序，然后合并小塊排序合成更大的塊。你可以知道計算層面的算法復(fù)雜度是NlogN, 數(shù)據(jù)的移動也是最優(yōu)化的。
那么在硬件設(shè)計層面如何對這個排序算法做特定設(shè)計？設(shè)計的自由度在于有多少數(shù)字需要被處理，以及IO的帶寬有多少？那么映射到這個歸并排序的合并樹就是你有多少的葉子結(jié)點以及每個節(jié)點的吞吐量有多大？做ASIC對這兩項進(jìn)行專門設(shè)計就比較有難度，我們可以做到的是，如果你告訴我需要排序1T字節(jié)的數(shù)據(jù)、100字節(jié)記錄實現(xiàn)原地歸并排序我們就可以給你定制一個最優(yōu)化的歸并樹。定制化的歸并樹設(shè)計好之后當(dāng)你實際去跑這個排序時你會發(fā)現(xiàn)1T字節(jié)的數(shù)據(jù)可能裝不進(jìn)內(nèi)存里，那又該怎么做呢？最好的解決方案是在以內(nèi)存的容量為塊的大小在內(nèi)存里排序，比如說你有256G的內(nèi)存那么你就排序256G大小的數(shù)。那么歸并就會發(fā)生在硬盤比如SSD里。SSD和內(nèi)存比帶寬小了很多，所以從DRAM的排序到SSD的歸并的數(shù)據(jù)轉(zhuǎn)移我們可以在線重構(gòu)FPGA來重新產(chǎn)生一個電路專門解決這個問題，這也是ASIC做不到的。這樣的定制化重構(gòu)電路僅需要花費(fèi)1秒鐘，整體的1T字節(jié)排序總共花費(fèi)200秒。相比于現(xiàn)有的CPU、GPU或者其他替代方案，我們的方案可以得到最優(yōu)的性能和最高的吞吐量。這項工作傳達(dá)的一個信息就是，FPGA可以在設(shè)計的開銷、性能和吞吐量之間給出一個較好的權(quán)衡考量。
02.實現(xiàn)高效可定制計算設(shè)計的五個關(guān)鍵
我很欣賞斯坦福大學(xué)Bill Dally教授寫的一篇文章《Domain-Specific Hardware Acclerators》。這篇文章總結(jié)了可定制計算的優(yōu)勢，并且闡述了一些得到高效的可定制設(shè)計的關(guān)鍵。第一點在于使用特殊的數(shù)據(jù)類型。比如說AI的推斷通常使用8比特數(shù)據(jù)類型。我們曾經(jīng)實現(xiàn)了基因測序的加速。在這個應(yīng)用中一般會有四種含氮堿基ATCG。我們用2比特的數(shù)據(jù)類型就可以表達(dá)這四種堿基。這可能會帶來10-1000倍的效率提升。第二點在于使用大規(guī)模并行計算。比如說在計算矩陣乘法時利用脈動陣列(Systolic Array)架構(gòu)，其每一個處理單元都可以處理數(shù)據(jù)。這種處理不是簡單的16路并行而是幾千路并行。這可以帶來極大的性能提升。第三點是優(yōu)化存儲。不需要使用標(biāo)準(zhǔn)的L1/L2/L3緩存架構(gòu)。數(shù)據(jù)就放在優(yōu)化好的內(nèi)存里，需要時取出就好了。這為高吞吐量低能耗的可定制計算提供了可能。第四點降低或者平攤額外的處理器開銷。在一般的芯片上做一個加法需要先獲取指令，解碼，然后獲取操作數(shù)，再根據(jù)其他指令的執(zhí)行情況安排執(zhí)行這條加法指令。實際上定制化計算做加法你只要拿到這兩個操作數(shù)用加法器加起來就可以了。其他的操作都是額外的處理器開銷。這種簡化的指令執(zhí)行可以帶來10000倍的效率提升。第五點是定制化計算不使用標(biāo)準(zhǔn)的處理器，既可以根據(jù)算法來設(shè)計芯片架構(gòu)，也可以根據(jù)架構(gòu)來考慮各類算法。這兩者是在定制環(huán)節(jié)中是可以一起考慮的。這幾點加起來，就可以提供和傳統(tǒng)標(biāo)準(zhǔn)處理器相比幾個數(shù)量級的性能和效率的提升。當(dāng)然ASIC也有和以上相同的優(yōu)勢。
03.軟件工程師設(shè)計專屬定制化加速器門檻有多高？
不過，我們之前提過ASIC的設(shè)計是一個昂貴又漫長的過程。使用FPGA雖然沒有ASIC的性能提升那么高，但是和一般處理器比性能的提升也是相當(dāng)顯著的。同時FPGA的設(shè)計周期極短，在需要時可以快速重構(gòu)，成本和ASIC比大大減小的優(yōu)勢，使我們覺得FPGA是讓大多數(shù)人可以體驗到可定制計算優(yōu)勢的首選方案。現(xiàn)在我希望已經(jīng)讓大家相信：讓軟件工程師為自己的應(yīng)用設(shè)計一款定制化加速器是一件重要而有趣的事情。那現(xiàn)階段軟件工程師可以很容易地設(shè)計出專屬的定制化加速器嗎？可能這個問題太寬泛了。很多軟件工程師的工作范圍可能觸及不到對性能的考量，只要設(shè)計出的軟件正常工作就可以。但實際上還有很多“認(rèn)真的”軟件工程師對程序的運(yùn)行性能有著很高的要求。他們在寫代碼的時候可能會關(guān)注處理的數(shù)據(jù)能不能放進(jìn)緩存里，是不是要改寫一下循環(huán)做循環(huán)分塊使得程序跑的更快。這些都是固定于現(xiàn)有架構(gòu)基于軟件層面的優(yōu)化。我希望這一類的軟件工程師更進(jìn)一步不需要很多硬件知識能夠很容易地設(shè)計出定制化加速器從來更好地提升性能提高效率。這是我們的目標(biāo)。只要你懂如何在普通CPU的情況下優(yōu)化軟件代碼，我可以讓你很容易地設(shè)計出你想要的加速電路。我們可以把問題精確到現(xiàn)階段這些“認(rèn)真的”軟件工程師身上，他們可以很容易地設(shè)計出專屬的定制化加速器嗎？我想說答案既是也不是。當(dāng)我一提到電路設(shè)計自動化，你可能會立刻想到高層次綜合（High-level Synthesis）。這是我們20年前的工作。高層次綜合可以將C/C++轉(zhuǎn)變成LLVM中間代碼。通過做各種代碼變換、調(diào)度安排和片上資源分配就可以得到RTL電路。我們這項工作從一個普通的學(xué)術(shù)項目xPilot為起點，然后基于它我們創(chuàng)立了AutoESL公司，不斷迭代xPilot變成AutoPilot。之后Xilinx收購了AutoESL，AutoPilot也變成了如今的Vivado HLS/Vitis HLS。
在收購之前Xilinx需要做完善的技術(shù)盡職調(diào)查。他們不僅自己在內(nèi)部進(jìn)行了測試，也雇傭了Berkerly Design Automation來進(jìn)行第三方測試。測試的結(jié)果表明，高層次綜合的結(jié)果（QoR）可以和手工設(shè)計的電路相媲美。IEEE TCAD將我們的最初驗證結(jié)果作為主旨論文發(fā)表在其2011年4月刊上。你可以在這篇文章里看見參照設(shè)計和高層次綜合生成設(shè)計的對比結(jié)果。高層次綜合確實是個好消息。利用高層次綜合可以很輕松的將C/C++程序轉(zhuǎn)換成電路。比如說下面這個Polybench的例子。這個例子中有兩個做矩陣乘法的循環(huán)。使用高層次綜合，你按一下按鈕就可以得到一個FPGA的設(shè)計，這條路已經(jīng)完全自動化了。
然而，這并不是故事的終點，不然我今天的主題報告到這里就結(jié)束了。實際上你會還會遇到以下幾個挑戰(zhàn)。第一個挑戰(zhàn)在于，當(dāng)你原原本本地將軟件代碼放進(jìn)高層次綜合工具，點完成按鈕測試了一下性能，發(fā)現(xiàn)這個電路比單線程CPU慢了13倍。那設(shè)計這樣一個比CPU還要慢的加速器又有什么意義呢？順帶一提，CPU一般的運(yùn)行頻率是2-4GHz，而FPGA的頻率是300-500MHz。這樣的性能差別其實很常見。在座的各位如果寫過并行程序如OpenMP的話，會發(fā)現(xiàn)你寫的第一個程序在16核CPU上并不會提高16倍的效率，甚至你可能幾乎看不見有任何性能提升。你要做的事情是去做運(yùn)行時間分析（profiling）。然后你會發(fā)現(xiàn)你需要給程序添加一些prgama來指明哪段代碼可以并行執(zhí)行，哪些需要做規(guī)約（reduction）等等。高層次綜合工具也提供了類似的pragma寫法。在下圖的例子里，我們就對兩個循環(huán)添加了pipeline, parallel和parallel with reduction三種pragma。我們回過頭來再看加了pragma的代碼產(chǎn)生的RTL發(fā)現(xiàn)性能提高了120倍。順帶一提這些pragma和Vitis_HLS的pragma略有不同。我們使用了Merlin編譯器來產(chǎn)生這些電路。Merlin是我們另外一家公司峰科計算（Falcon Computing）的產(chǎn)品。Xlinx在兩年前收購了峰科之后也將Merlin編譯器開源供各位試用。
開源地址：https://github.com/Xilinx/merlin-compilerMerlin編譯器的好處在于它自動實現(xiàn)了一般高層次綜合手寫才能做的很多代碼優(yōu)化，需要額外添加的pragma數(shù)量和一般高層次綜合相比大大減少。你們可以看見這個例子只用3個pragma就可以了。Merlin的pragma只有簡單的pipeline, parallel和tiling三種?？偟膩碚f我們想告訴大家的是軟件代碼需要添加合適的pragma來產(chǎn)生高性能的RTL電路。
現(xiàn)在你說，好，如果我添加三個pragma就可以產(chǎn)生120倍性能提升的電路，那么我怎么知道在哪里添加什么pragma呢？這就涉及到我想說的第二個挑戰(zhàn)。以Merlin編譯器為例子，我們已經(jīng)知道Merlin只有pipeline、parallel和tiling三種pragma，你可能需要在每個循環(huán)上把這三種pragma以及對應(yīng)不同的參數(shù)都試一遍。就算你的程序很簡單只有四五個循環(huán)，這樣的求解空間都是指數(shù)級。對于我們圖示的簡單例子可能就有超過三百萬種設(shè)置，一個個手工窮舉并不是一件合理的事情。那我們怎么來解決這個挑戰(zhàn)呢？
下面我想介紹一下為了解決這個挑戰(zhàn)我們做的幾方面工作。為了民主化可定制計算：即讓大家都可以用！我們希望不僅是C/C++語言能用來設(shè)計電路，更上層的語言或工具比如TensorFlow、Halide、Spark等都可以用來描述和設(shè)計電路。然后對這些更高層次的語言有一些通用的中間表示層如HeteroCL/MLIR。我們之后會詳細(xì)描述這些工作。
04.讓軟件工程師暢通無阻生成高性能加速器
我會從三個不同的角度來描述我們的工作。第一個角度我稱之為架構(gòu)導(dǎo)向優(yōu)化（Architecture Guided Optimization）。如果我知道某些特定的架構(gòu)模板對特定的應(yīng)用有很大優(yōu)勢那么我就使用這些特定模板。這樣的例子包括脈動陣列（Systolic Array, DAC‘17）和模板計算（Stencil, ICCAD’18）。還有一類新的架構(gòu)我們稱之為可組合可并行可流水架構(gòu)（CPP, DAC’18）。第二個角度，我們的初步研究相信利用機(jī)器學(xué)習(xí)或者深度學(xué)習(xí)來進(jìn)行優(yōu)化設(shè)計是有可能的，我們之后會提到相關(guān)的工作。第三點基于上述兩個角度，我們希望可以把各種加速器快速地組合在一起，我們也有一些相應(yīng)的工作。我們的目標(biāo)是使得軟件工程師可以在他們熟悉的高層次語言描述上可以一路到底暢通無阻的生成他們需要的高性能加速器。
首先來談?wù)劦谝粋€角度，架構(gòu)導(dǎo)向優(yōu)化。我們的工作的其中一個例子是AutoSA。這項工作主要是深度學(xué)習(xí)的高層次代碼核（Kernel）映射到脈動陣列上。脈動陣列在上世紀(jì)70年代由H. T. Kung教授和Charles Leiserson教授提出并給出了形式化的定義。大概的意思是數(shù)值的計算是可以像心跳一樣舒張收縮脈動化的，比如在3x3矩陣相乘時，行列向量之間錯拍輸入處理單元（PE），結(jié)果可以按節(jié)拍輸出（譯者記：行列輸入分別在1,2,3拍進(jìn)入，按列為單位輸出分別在第3,4,5拍, 第4,5,6拍, 第5,6,7拍產(chǎn)生）。
為什么我們對脈動陣列這么感興趣呢。因為這里面包含了很多大型矩陣和大量的并行處理，這帶來了性能提升。谷歌的TPU就是基于脈動陣列的架構(gòu)進(jìn)行設(shè)計的。脈動矩陣的另一個關(guān)注點在于局部臨近計算，這優(yōu)化了能耗。對傳統(tǒng)芯片設(shè)計主要的性能影響指標(biāo)并不是門的速度而是導(dǎo)線的速度。脈動陣列的布線只連接了相鄰的處理單元。所以現(xiàn)在幾乎所有的，包括谷歌、特斯拉和亞馬遜的深度學(xué)習(xí)加速器都在基于脈動陣列來設(shè)計。雖然脈動陣列的原理很簡單，然而要設(shè)計出一塊好的脈動陣列加速器并不是一件容易的事情。下面這幅研發(fā)周期分析圖來自英特爾，他們展示了從包括C、OpenCL、Verilog、SystemVerilog等語言開始到生成硬件電路的研發(fā)周期。其中紅色高亮的三個設(shè)計使用到了脈動陣列。我們可以看到研發(fā)這樣的電路少則4個月，多則18個月。設(shè)計出的可能只是一個性能還可以的電路，不是最終完全調(diào)優(yōu)的電路。我們希望自動化這一步驟。實現(xiàn)自動化的挑戰(zhàn)在哪里呢？挑戰(zhàn)在于不僅僅可以設(shè)計出一個脈動陣列的電路，而且是根據(jù)不同參數(shù)自動設(shè)計出最優(yōu)的或者接近于最優(yōu)的電路。所以，我們提出了設(shè)計空間的概念。比如說你有輸入數(shù)組的參數(shù)以及所有可能的脈動陣列參數(shù)等等，這些參數(shù)的笛卡爾積就構(gòu)成了一個待求解的設(shè)計空間。我們的工作已經(jīng)可以在這個求解空間內(nèi)自動尋找最優(yōu)解或者接近于最優(yōu)的設(shè)計。接下來的工作我們又分成兩大步驟，一個是計算管理，另一個是通信管理。對于計算管理，我們這里用一個三循環(huán)的矩陣乘法來展示一下工作原理。這里第一個需要考慮的問題就是時間-空間映射。對這三個循環(huán)，你需要決定哪幾個循環(huán)可以映射到二維的空間域上同時計算，哪幾個循環(huán)映射到一維時間維度上在處理器上進(jìn)行常規(guī)的時間循環(huán)。解決這個問題我們使用了多面體模型（Polyhedral Model）來分析數(shù)據(jù)依賴，然后做一定程度上的窮舉來縮小求解空間從而劃出存在著最優(yōu)解的子集。
第二個需要考慮的問題是數(shù)據(jù)量。你的數(shù)據(jù)量可能特別大，比如說你需要處理10x24x24字節(jié)的數(shù)據(jù)，因為數(shù)據(jù)量大可能沒有辦法做到計算單元和每一個數(shù)據(jù)的對應(yīng)。你可能需要創(chuàng)建多個小一點的數(shù)組作為替代，我們稱之為數(shù)組分塊（Array Partition）。見圖中的實例，你可以把循環(huán)劃分出一個個小塊并在每一個小塊上產(chǎn)生一個新的循環(huán)。這里我們會對產(chǎn)生多大的小塊這一參數(shù)進(jìn)行優(yōu)化。
這還沒有完，第三個需要考慮的問題就是時序。真正的電路并沒有像當(dāng)前時刻做計算然后傳到右邊的鄰接節(jié)點然后在下一個時刻做新的計算這么簡單。很多的運(yùn)算比如說浮點數(shù)加乘需要花費(fèi)好幾個時鐘周期。如果不做任何優(yōu)化，相鄰的處理單元可能需要等上5-10時鐘周期才能得到數(shù)據(jù)。一個更好的方式是我先開始計算一部分?jǐn)?shù)據(jù)，比如說要花8個時鐘周期。接著我立刻在下一時鐘周期對一塊沒有數(shù)據(jù)依賴的獨(dú)立區(qū)域進(jìn)行計算，這樣每個時鐘周期我都能給相鄰的處理單元一些數(shù)據(jù)。這就意味著你可能需要額外再分離出一些循環(huán)來實現(xiàn)上述操作，我們稱之為延時隱藏（Latency Hiding）。
最后你的脈動陣列處理單元不一定只能做一次加乘操作，這其中可以進(jìn)行SIMD處理。你可以有一個向量來同時處理16個運(yùn)算。這也會產(chǎn)生額外的循環(huán)我們稱之為SIMD循環(huán)。以上就是我們在計算管理上幾個角度的考量。這些考量合在一起就形成了一個大的自動化求解空間。你也可以看見因為空間很大，我們也需要花一些時間來找到最優(yōu)或接近最優(yōu)的脈動陣列電路設(shè)計。
到現(xiàn)在為止對數(shù)據(jù)計算管理就有這么多的選項，對數(shù)據(jù)傳輸通信呢？其實傳輸通信才是關(guān)鍵，因為你要保證數(shù)據(jù)只在相鄰的處理單元之間傳遞而不是廣播數(shù)據(jù)。我們通過做依賴分析來解決這個問題。你可以在這個矩陣乘法的例子中發(fā)現(xiàn)A和B矩陣各自都有讀后讀依賴（Read-after-Read dependency）。一般來說在CPU中我們對讀后讀依賴不是很看重，但在脈動陣列設(shè)計中這非常重要。接著我們發(fā)現(xiàn)操作中還有寫后讀的依賴（Read-after-Write dependency）因為C矩陣是在循環(huán)之間累加的。最后不同的數(shù)值會寫在C矩陣不同的位置上。接著你就能得到下圖中的這張表來發(fā)現(xiàn)哪一個I/O組有著怎樣的數(shù)據(jù)依賴關(guān)系。
有了這張表你就可以知道如何構(gòu)建網(wǎng)絡(luò)架構(gòu)。比如說根據(jù)你的依賴向量你發(fā)現(xiàn)依賴是沿著j軸的那你就可以沿著j軸傳輸數(shù)據(jù)流。同理，如果依賴沿著i軸那么就沿i軸傳輸數(shù)據(jù)流。這些分析都是通過多面體分析得來的，基于這個分析得出的傳輸網(wǎng)絡(luò)，我可以保證是依賴正確，同時只有相鄰處理單元有數(shù)據(jù)傳輸。當(dāng)然所有計算完成之后數(shù)據(jù)會被讀回去。我在這里不會詳細(xì)展開這個分析，但是我很樂于分享相應(yīng)的論文給大家參考。
以上的步驟中有些參數(shù)是我們需要去調(diào)整的。其中很重要的是循環(huán)分塊（loop tiling）的參數(shù)。你需要決定執(zhí)行循環(huán)的數(shù)組的維度是多少。為了找到這個參數(shù)我們采取了一種混合方法。首先我們用一個數(shù)學(xué)優(yōu)化求解器，然后我們做進(jìn)化搜索，因為找到的參數(shù)可能存在無法整除的情況。我想強(qiáng)調(diào)的是之所以我稱之為基于微架構(gòu)的優(yōu)化是因為一旦你定義好了微架構(gòu)的模板我就可以根據(jù)這個架構(gòu)來快速準(zhǔn)確的估計設(shè)計電路的性能。這使得使用數(shù)學(xué)求解器成為了可能。我們目前已經(jīng)將AutoSA開源。歡迎大家來試用這個工具，并給這個工具添加新的功能。
開源地址：https://github.com/UCLA-VAST/AutoSA我也可以告訴大家，當(dāng)你擁有了這樣的基于具體架構(gòu)的空間求解器你可以得到一些令人驚訝的結(jié)果。其中一個新洞察是物理數(shù)組的大小應(yīng)該是多少，這個大小一定需要是總體數(shù)據(jù)大小的因數(shù)嗎？比如說總大小是1024，是不是只能去嘗試2、4、8、16這樣的因數(shù)作為物理數(shù)組的大小呢？實際上，有不少文章是基于這樣的假設(shè)來做設(shè)計空間求解的。這些文章也發(fā)表在了頂級的期刊或會議上。但是我們證明了這條假設(shè)不是一定正確的。原因很簡單，如下圖所示如果一個4x32的設(shè)計是可以裝進(jìn)FPGA的，8x32則裝不下，在這個設(shè)計里如果你用一些非因數(shù)參數(shù)（13x16）反而有更好的效果。這個矩陣乘法的例子我們可以很明確地告訴大家根據(jù)純因數(shù)參數(shù)最好的設(shè)計參數(shù)為32x4x8（行，列，SIMD），但如果你選一些奇怪的數(shù)字比如說16x13x8我們甚至可以獲得50%的性能提升，這是令人意想不到的。
另外一個驚人的洞察是很多人知道片外的存儲轉(zhuǎn)移是很重要的。不對此進(jìn)行優(yōu)化，很難得到最優(yōu)化的設(shè)計。很多人說只要最小化存儲轉(zhuǎn)移的量，我應(yīng)該就可以得到最優(yōu)化的設(shè)計。當(dāng)然也有一些文章是基于這樣的假設(shè)。再一次地，我們證明了這不一定永遠(yuǎn)正確。我們還是使用剛才的例子，如果你計算一下數(shù)據(jù)移動你會發(fā)現(xiàn)第二個設(shè)計有著更高的移動。這是一個高計算密度的應(yīng)用所以計算量是很重要的，增加的數(shù)據(jù)移動保證了所有的計算單元都被有效利用了。
以上例子顯示了有些工作如果你如果沒有用到空間求解你可能就無法真正研究到這種設(shè)計細(xì)節(jié)。順帶一提，我們的工作不僅實現(xiàn)了對脈動陣列的優(yōu)化，而且優(yōu)化了一些模板計算（Stencil Computation）。這些模板計算也在數(shù)據(jù)管理和通信管理上做到了最優(yōu)化。希望現(xiàn)在你可以相信脈動陣列我們可以做得很好。但是對于沒有經(jīng)典架構(gòu)可以映射的一般程序，是否也可以做好呢？在這個問題上我們使用峰科計算開發(fā)的Merlin編譯器來解決這個問題。我們將Merlin編譯器設(shè)計成和OpenMP類似的使用方式。OpenMP是很多軟件工程師開發(fā)多核CPU程序的應(yīng)用程序接口。我們認(rèn)為這樣的設(shè)計可能是最貼近于軟件工程師使用習(xí)慣的。在OpenMP里怎么讓程序并行執(zhí)行呢？和高層次綜合類似，你用pragma來做這件事情。OpenMP的pragma以”omp parallel for”為前綴，你可以把它加在需要并行執(zhí)行的循環(huán)之前并指定并行執(zhí)行的參數(shù)。類似地在Merlin編譯器里，我們使用”ACCEL”作為前綴，你可以對循環(huán)指定pipeline，parallel和tiling的操作并指定對應(yīng)的優(yōu)化參數(shù)。比如這里的例子我們就指定對循環(huán)做16路并行。Merlin編譯器會自動執(zhí)行很多的代碼變換。這些變換包括將數(shù)據(jù)裝入緩沖存儲器（Buffer）、數(shù)組劃分（Array Partition）、上位機(jī)代碼生成等等。這些所有的步驟都是全自動的。對于軟件工程師來說這非常容易上手。
基于Merlin編譯器，我們所做的第一項工作叫自動設(shè)計空間求解（AutoDSE）。這項工作也獲得了ACM TODAES 2023年度最佳論文獎。AutoDSE的工作原理類似一個專家系統(tǒng)。一般來說如何去設(shè)計一個加速電路呢？極大概率你會想從什么pragma也不加開始，當(dāng)然有可能很幸運(yùn)的，什么pragma不加就能用Merlin達(dá)到性能目標(biāo)。從一個沒有pragma的程序出發(fā)，你先會去看一下Merlin的輸出報告。從報告上不僅可以看見總的時鐘周期，也可以看見詳細(xì)到每個循環(huán)的時鐘周期分布以及資源使用情況。這樣很明顯你可以發(fā)現(xiàn)某幾個嵌套循環(huán)占據(jù)了大量的延時。知道這一點之后你就會在相應(yīng)的循環(huán)上添加pragma來提升性能。如此循環(huán)往復(fù)直到獲得滿意的設(shè)計。我稱之為基于瓶頸指向的優(yōu)化設(shè)計。AutoDSE可以通過空間求解自動產(chǎn)生pragma及其參數(shù)，并調(diào)用Merlin編譯器實現(xiàn)了自動化求解。然而AutoDSE有一個限制在于，對于每次迭代求解我都必須運(yùn)行高層次綜合以了解性能。一次執(zhí)行可能需要10分鐘，有時20分鐘，有時30分鐘，所以一天之內(nèi)你很難經(jīng)歷很大量多次迭代，也許最多20-40次。一個設(shè)計求解空間中可能有數(shù)百萬個點，因此我們認(rèn)為這可能是深度學(xué)習(xí)可以提供幫助的地方：我們想要提出一個模型，可以給我們正確的性能預(yù)測。如果機(jī)器學(xué)習(xí)可以成為最好的國際象棋棋手，也許它也可以成為即將到來的最好的電路設(shè)計師。我們實際上研究發(fā)現(xiàn)這比下棋要困難得多。因為圍棋雖然是相當(dāng)具有挑戰(zhàn)性的大棋盤，但它的規(guī)則是固定的。但是加速器電路設(shè)計，例如編寫算法，都是開放式的沒有固定的規(guī)則。你只受你的創(chuàng)造力的限制，所以這是一個更加難的問題。我們的第一個目標(biāo)是給程序和pragma準(zhǔn)確預(yù)測性能，這樣我就可以在設(shè)計空間里快速迭代。對于AlphaGo的設(shè)計師來說最激動人心的時刻還在于，一旦你擁有了棋盤，你就擁有了黑色棋子、白色棋子和規(guī)則。一旦他們看見棋盤的局勢他們就可以產(chǎn)生對應(yīng)的評分函數(shù)進(jìn)行預(yù)測，這是他們可以進(jìn)行機(jī)器學(xué)習(xí)的關(guān)鍵。我們也想做同樣的事情，當(dāng)我看到程序員的程序時，我也想建立一個評分函數(shù)對其進(jìn)行性能評估。另一個問題是我該如何預(yù)處理這些帶pragma的程序，你是把它當(dāng)作一串字符向量、自然語言還是別的什么量化表示。事實上，我發(fā)現(xiàn)程序與自然語言非常不同，因為當(dāng)我在這里說話時，有很多的冗余詞，你可以跳過也許五個詞你仍然可以知道我在說什么。但是對于一個程序它敏感到如果你放錯了分號，你會得到一個非常不同的結(jié)果。所以對于程序直接使用自然語言處理并不是一個很好的方式。
我們在這里想解的決問題依然是希望能夠自動插入pragma。然后我們快速地搜索這個求解空間。我們要做的第一件事情是創(chuàng)建訓(xùn)練樣本。這個時候AutoDSE就可以發(fā)揮巨大的作用，原因是AutoDSE的求解過程中會產(chǎn)生大量的中間設(shè)計結(jié)果，我們不僅保留了這些電路的性能指標(biāo)也保存了這些對應(yīng)的電路設(shè)計。這些AutoDSE生成的樣本電路可以作為我們的訓(xùn)練樣本，不僅是因為我們進(jìn)行了針對瓶頸的優(yōu)化使得這些中間設(shè)計仍然是有意義的，盡管它不是最優(yōu)的。而且我們對有些電路也做了一些擾動使得我們生成的訓(xùn)練樣本包括好的和壞的設(shè)計。我們通過這樣的方式創(chuàng)建包含有幾千個程序的訓(xùn)練樣本數(shù)據(jù)庫。我也希望您可以與我們合作，也許在更大的社區(qū)范圍內(nèi)我們可以制作一個更多更大的樣本數(shù)據(jù)庫。圖神經(jīng)網(wǎng)絡(luò)有很多令人興奮的進(jìn)展。事實上，我注意到在我的主題報告之后有一個關(guān)于圖神經(jīng)網(wǎng)絡(luò)的研討會。我認(rèn)為這非常及時。我們將把圖編碼成多維向量或者多個多維向量的嵌入（Embedding）。在編碼成向量之前我們需要考慮節(jié)點的注意力機(jī)制（Attention）、知識跳躍（Jumping knowledge）等等很多因素。有了這個圖的嵌入編碼，就可以作為高維神經(jīng)網(wǎng)絡(luò)的輸入層，然后把對應(yīng)的性能指標(biāo)作為訓(xùn)練標(biāo)簽進(jìn)行訓(xùn)練了。
這樣的做法和純用AutoDSE相比就快多了。我也不必運(yùn)行高層次綜合就可以做設(shè)計空間求解。我們在第一個版本中選擇最好的M個設(shè)計，然后對M個設(shè)計再進(jìn)行高級綜合來作為新的訓(xùn)練數(shù)據(jù)集。但這還不是故事的結(jié)束。對于和訓(xùn)練集完全不一樣設(shè)計使用圖神經(jīng)網(wǎng)絡(luò)我們還是有一些掙扎的。這些測試樣本對于訓(xùn)練來說屬于域外分布。所以這就是我們想要利用遷移學(xué)習(xí)（Transfer Learning）的地方（GNN-DSE-MAML）。大概的做法是如果你給我一些全新的東西，我要建立一個模型，我必須運(yùn)行在一些樣本上運(yùn)行幾次真正的高層次綜合，然后我更新我的模型而不是直接使用已有數(shù)據(jù)進(jìn)行探索。
我們這個方法的靈感來源于機(jī)器學(xué)習(xí)中K樣本學(xué)習(xí)（K-shot learning）的概念。用早期的分類工具我可以從一百萬張圖像中學(xué)會如何區(qū)分一千個類別的狗和貓或其他物件。那現(xiàn)在如果我給你一種新動物比如說駱駝，你從來沒有見過你能認(rèn)出嗎？顯然必須教你一些東西，但也許只要有兩三個駱駝的照片你就可以知道這是駱駝，你以后可以一直分辨出來。如何來做這件事情？基本上你將會有一些動物，每一種都有一些例子。每一個新動物都稱為一項任務(wù)，你希望在所有這些任務(wù)上都做好。每個任務(wù)的樣本數(shù)很少，你也想要在這些任務(wù)之間做好區(qū)分。數(shù)學(xué)上發(fā)生的事情是你迭代所有這些任務(wù)，你進(jìn)行梯度下降，每個任務(wù)都會給你一個新的梯度，然后你做某種加權(quán)平均然后你取得了訓(xùn)練進(jìn)展。在推理時，當(dāng)你看到一個新任務(wù)，基本上是一種新動物或在我們的情況是一個新程序，然后你會先運(yùn)行幾張圖，找到現(xiàn)有最小化誤差，所以給你另一個梯度，然后你從這個梯度出發(fā)來更新現(xiàn)有的模型。
這是我們做自適應(yīng)的方法。利用這個方法我們得到了魯棒性更好的結(jié)果。這個結(jié)果是比直接微調(diào)更好的。我會說我們還是有優(yōu)化的空間，尤其是在資源管理部分。因為在某些情況下我們得到了很好的結(jié)果，但它已經(jīng)超出了我們擁有的資源，所以我們必須更精確地處理這些情況。
AutoDSE（https://github.com/UCLA-VAST/AutoDSE）和GNN DSE（https://github.com/UCLA-VAST/GNN-DSE）都是開源的，所以如果您有興趣在這個方向繼續(xù)研究，歡迎您下載試用。
HeteroCL這項工作非常成功，我們將其硬件優(yōu)化部分?jǐn)U展到我們的加速器設(shè)計。在這里我們主要有三種優(yōu)化方式。第一種是特定計算的定義。比如我們可以來定義一個循環(huán)的展開。第二種是自定義數(shù)據(jù)類型。你可以很容易地嘗試從2bit到16bit，看看你的輸出結(jié)果是什么樣子。我們也可以指定如何復(fù)用數(shù)據(jù)。
接下來我們很快意識到，在硬件優(yōu)化的定義區(qū)塊中，我們可以給用戶使用微架構(gòu)的設(shè)計自由。比如說其中某些計算可以使用脈動陣列，某些計算可以使用模板計算。這些都是設(shè)計模式，和真正的硬件指標(biāo)比如FPGA中的BRAM或者URAM的使用毫不相關(guān)。軟件設(shè)計師可以很容易地和他們平常寫設(shè)計一樣指定這些模式。其他指定不了的步驟我們將通過自動合成、AutoDSE和機(jī)器學(xué)習(xí)等等技術(shù)幫助他們自動完成。
05.結(jié)語：民主化可定制計算取得的進(jìn)展令人鼓舞
最后，在我的主旨報告結(jié)束之前，我想再談一個問題：即如何將所有東西搭建在一起？對于一些真正從事FPGA設(shè)計的人來說，當(dāng)你把所有東西放在一起時，性能可能從大約300MHz降至100MHz。而且還需要非常長的時間生成比特流。20小時并不夸張，40小時完全合理。我們最近在這個問題上取得了很大的進(jìn)步。順便說一句，你不必因為設(shè)計錯了什么而感到難過，只是大型的FPGA非常復(fù)雜。你可能注意到了一個大的FPGA往往有四個大片（die）而不是一個。如果你的設(shè)計出現(xiàn)了跨片的情況整個電路的延時可能一下子就從幾納秒漲到幾十納秒。而且大型FPGA中還有很多IP核在那里阻礙了很多布局布線。比如說你有DDR、控制器在中間，然后你有PCIe控制器在最后與CPU通信。最新的FPGA有32個通道的HBM。那么如何連接到你需要的數(shù)據(jù)你需要創(chuàng)建一個大的交叉通信模塊，這也會犧牲芯片的性能。有了以上原因，你的FPGA實際表現(xiàn)很差并不是一件奇怪的事情。HLS對這一點的考慮也是有限的。你在編寫代碼和插入pragma時不知道在實際布局布線中你會在哪里出現(xiàn)跨片，在哪里會遇到哪些IP塊。我們的解決方法實際上很簡單。如果你有一根高延時長線我可以通過增加流水線級數(shù)來解決這個問題。所以問題轉(zhuǎn)變?yōu)檫@些長線在哪里。這就是我們要先做布局的地方，這是一個粗略等級的布局。然后利用這個粗略的布局信息作為約束條件來指導(dǎo)全局的優(yōu)化。從高層次綜合開始實際上是理想的，因為我基于一種抽象表示做調(diào)度比較自由。如果我需要兩個額外的時鐘周期我可以將其添加到我的調(diào)度解決方案中。這個方法也是比較成功的。現(xiàn)在我們在超過43種設(shè)計中看到幾乎是2倍的時鐘周期提升，從150MHz到 297MHz。我可以告訴你，每一個我實驗室的項目都在使用Autobridge進(jìn)行FPGA輔助設(shè)計， 因為學(xué)生自然而然能獲得2倍的性能提升。這項工作獲得了 FPGA’2021的最佳論文獎。如果你對此感興趣，歡迎與你的團(tuán)隊分享這項工作。
不僅如此，我可以繼續(xù)向你展示關(guān)于脈動陣列的設(shè)計討論。從12 x 12陣列開始到24 x 24陣列時，在傳統(tǒng)情況下你會發(fā)現(xiàn)性能下降，頻率從300MHz開始降至150MHz或120MHz，但用AutoBridge優(yōu)化后，我們的運(yùn)行頻率基本上保持不變。所以你可以看到圖中的布局布線圖是一個很神秘的部分，左邊的圖中布局布線工具看起來似乎做得很好，他們將所有東西都包裝在盡可能少的片中，但是他們造成大量布線擁堵（Congestion）。我們可以放心地將其分離出來，然后我們將流水線寄存器按需插入設(shè)計。
這些我稱之為延遲激勵設(shè)計技術(shù)，因為你可以容忍比較長的延遲，也可以幫助我們改善布局布線。如果你運(yùn)行Xilinx工具，你發(fā)現(xiàn)它太慢了要40小時，你分析一下CPU使用情況發(fā)現(xiàn)你只使用了四個核。你說我有32個核，為什么不使用32個核？因為你無法并行優(yōu)化各個電路，因為片與片之間存在全局互連。使用這種方法，我們在邊界添加觸發(fā)器，因此每個觸發(fā)器完全解耦了片間連接，以便我們可以并行運(yùn)用它們。
這種技術(shù)實際上也可以帶來驚人的結(jié)果。我們獲得5到10 倍編譯綜合運(yùn)行速度的提升，我們還獲得了30%頻率提升。
我們還有一個擴(kuò)展，被稱為TAPA的HLS?；旧衔覀兲砑右恍┠０錓O來描述這些數(shù)據(jù)。從那里進(jìn)行流程設(shè)計，我們可以利用之前提到的技術(shù)自動進(jìn)行延遲激勵優(yōu)化。
我們使用TAPA設(shè)計了一個FlexCNN。它共計有14000行代碼，這一切都使用了延遲激勵設(shè)計。
最后總結(jié)一下，我知道民主化可定制計算這個方向存在的時間很短，但對在這個方向上所取得的進(jìn)展，我倍感鼓舞。也許我有些偏愛，在報告中我選擇了更多來自我的實驗室所做的研究，但實際上這個領(lǐng)域有著一群共同努力的優(yōu)秀學(xué)者。這確實需要整個社區(qū)的共同努力，這就是為什么我們對工具開源這件事情如此強(qiáng)調(diào)。我希望聆聽或者是閱讀我報告的人，能夠在這個領(lǐng)域繼續(xù)添磚加瓦。工業(yè)界也正在朝著開源這個方向發(fā)展，并且會更加開放，例如英特爾有一個可定制計算API 是開源的。同時在我們的鼓勵下，AMD-Xilinx在收購峰科計算之后也開源了Merlin編譯器。我們對使用MLIR作為加速器設(shè)計的也越來越感興趣。你們很多人可能都聽過Hennessy教授和Patterson教授在他們的圖靈獎演講中的一句話：“這是一個計算機(jī)架構(gòu)的黃金時代”。這絕對是真的。因為以前你只有微處理器、控制器等一些很少類型的東西可以設(shè)計。現(xiàn)在有了所有這些加速器的設(shè)計，實際上產(chǎn)生了無限的機(jī)會。開源軟件生態(tài):
AutoSA: https://github.com/UCLA-VAST/AutoSA
Stencil: https://github.com/UCLA-VAST/soda
Merlin Compiler:
https://github.com/Xilinx/merlin-compiler
AutoDSE: https://github.com/UCLA-VAST/AutoDSE
GNN-DSE: https://github.com/UCLA-VAST/GNN-DSE
HeteroCL: https://github.com/cornell-zhang/heterocl
AutoBridge:
https://github.com/UCLA-VAST/AutoBridge
TAPA: https://github.com/UCLA-VAST/tapa
FlexCNN with TAPA:
https://github.com/UCLA-VAST/FlexCNN
參考鏈接:
[1]主旨報告演講視頻：
https://www.youtube.com/watch?v=qlqjymTcLdI
[2]主旨報告幻燈片：
https://ucla.box.com/s/8yx0m0v1wtobn0io87jg4xh4sw0fculp
[3]Wang, Jie, Licheng Guo, and Jason Cong. "AutoSA: A polyhedral compiler for high-performance systolic arrays on FPGA." The 2021 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays. 2021.
[4]Chi, Yuze, and Jason Cong. "Exploiting computation reuse for stencil accelerators." 2020 57th ACM/IEEE Design Automation Conference (DAC). IEEE, 2020.
[5]Chi, Yuze, Jason Cong, Peng Wei, and Peipei Zhou. "SODA: Stencil with optimized dataflow architecture." In 2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), pp. 1-8. IEEE, 2018.
[6]Cong, Jason, Muhuan Huang, Peichen Pan, Yuxin Wang, and Peng Zhang. "Source-to-source optimization for HLS." FPGAs for Software Programmers (2016): 137-163.
[7]Wei, Xuechao, Cody Hao Yu, Peng Zhang, Youxiang Chen, Yuxin Wang, Han Hu, Yun Liang, and Jason Cong. "Automated systolic array architecture synthesis for high throughput CNN inference on FPGAs." In Proceedings of the 54th Annual Design Automation Conference 2017, pp. 1-6. 2017.
[8]Sohrabizadeh, Atefeh, Cody Hao Yu, Min Gao, and Jason Cong. "AutoDSE: Enabling software programmers to design efficient FPGA accelerators." ACM Transactions on Design Automation of Electronic Systems (TODAES) 27, no. 4 (2022): 1-27. (ACM TODAES best paper award)
[9]Sohrabizadeh, Atefeh, Yunsheng Bai, Yizhou Sun, and Jason Cong. "Automated accelerator optimization aided by graph neural networks." In Proceedings of the 59th ACM/IEEE Design Automation Conference, pp. 55-60. 2022.
[10]Lai, Yi-Hsiang, Yuze Chi, Yuwei Hu, Jie Wang, Cody Hao Yu, Yuan Zhou, Jason Cong, and Zhiru Zhang. "HeteroCL: A multi-paradigm programming infrastructure for software-defined reconfigurable computing." In Proceedings of the 2019 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pp. 242-251. 2019. (Best paper award candidate)
[11]Pal, Debjit, Yi-Hsiang Lai, Shaojie Xiang, Niansong Zhang, Hongzheng Chen, Jeremy Casas, Pasquale Cocchini et al. "Accelerator design with decoupled hardware customizations: benefits and challenges." In Proceedings of the 59th ACM/IEEE Design Automation Conference, pp. 1351-1354. 2022.
[12]Guo, Licheng, Yuze Chi, Jie Wang, Jason Lau, Weikang Qiao, Ecenur Ustun, Zhiru Zhang, and Jason Cong. "AutoBridge: Coupling coarse-grained floorplanning and pipelining for high-frequency HLS design on multi-die FPGAs." In The 2021 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pp. 81-92. 2021. (Best paper award)
[13]Chi, Yuze, Licheng Guo, Jason Lau, Young-kyu Choi, Jie Wang, and Jason Cong. "Extending high-level synthesis for task-parallel programs." In 2021 IEEE 29th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM), pp. 204-213. IEEE, 2021.
[14]Basalama, Suhail, Atefeh Sohrabizadeh, Jie Wang, Licheng Guo, and Jason Cong. "FlexCNN: An End-to-End Framework for Composing CNN Accelerators on FPGA." ACM Transactions on Reconfigurable Technology and Systems 16, no. 2 (2023): 1-32.
[15]Sohrabizadeh, Atefeh, Jie Wang, and Jason Cong. "End-to-end optimization of deep learning applications." In Proceedings of the 2020 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pp. 133-139. 2020.
加入技術(shù)交流群
