從今年開始，計算機協會（ACM）第20屆FPGA國際研討會將舉辦未來研討：FPGA在20年后會是什么樣。來自供應商、用戶和學術團體的各界專家將參加這一活動，盡可能對未來做出確定性的最終預言。

　　通過總結最佳工程，七名演講人將回顧可編程器件過去20年的歷史，總結出趨勢線，在此基礎上，進行推演。專家們將從三個主要領域為FPGA未來勾畫出草圖：工藝技術、體系結構，以及用于對器件編程的隱喻和工具。

　　工藝技術

　　微電子技術過去二十年的發展將勾畫出FPGA的未來。演講人普遍認為，到2032年，推動這種發展的主要因素毫無疑問仍然是CMOS的尺度演進。

　　Xilinx CTO兼資深副總裁Ivo Bolsens認為：“硅片的發展仍將持續25年或者30年。在2030之前，我認為這一領域不會有新材料出現。”

　　Altera CTO兼研發資深副總裁Misha Burich提出了研討話題，他有相似的觀點，從量子晶體管到DNA，羅列了很多吸引人的技術，但是，他沒有打算進行深入的討論。他繼續發表言論，認為Altera的工藝發展將持續到2026年以后。Burich評論說：“自此之后，仍然可以使用摩爾定律作為標準。”

　　那么，摩爾定律底揭示了什么呢？Burich認為：“在2032年，我們會推出1.8-nm工藝，具有3-nm特征尺寸和metal-1間距。這意味著，我們可以在一個管芯上實現8千8百70億個晶體管。”Burich預計，這類FPGA要比今天的器件吞吐量高出250倍。但是，CTO提醒說，對于硅片，3 nm只有13個原子間隔。即使采用了原子級工藝控制技術，與目前很多電路設計的容限相比，簡單的量化舉例，一個12個原子長的溝道和一個14個原子長的溝道，在晶體管上都會有很大的變化。雖然更小的晶體管速度會更快，但是互聯會非常慢，需要重新審視電路拓撲的傳統觀點，實際上，這需要突破基于單元的設計方法。

　　倫敦皇家學院電氣和電子工程系主任Peter Cheung在這一問題上闡述了一些面臨的實際困境。Cheung預言說：“如果您想在2032年設計一款每個晶體管都能夠正常工作的芯片，那么，您的產出是零。實際上，工藝變化會使得每一個芯片在物理上都是獨一無二的。而且，在制造結束時，這種差別仍然會存在。”

　　Cheung提醒說：“這就帶來了問題。我們已經知道，隨著時間的推移，很多機制，包括，缺陷電荷、熱載流子效應、阻抗提高以及離子擴散等，會明顯的劣化電路。這些效應目前對于芯片的工作影響是不明顯的，但是，在20年內會變得越來越明顯。”

　　在某種程度上，Cheung認為這是可編程邏輯的一種機遇。他建議，可編程器件不僅僅是實現系統的一種方法，在2032年，每一個系統級器件都是可編程的：在運行時，芯片會將其仍然在運轉的資源配置到工作系統中。Cheung評論說：“有鑒于此，我們認為可重新配置能力會有新機遇。它們包括器件專用微調功能；自測試、特性測試和診斷；失效預測；進行重新配置，從失效中恢復；避免最差情況下的設計；以及隨時間變化的損耗均衡等，這都延長了芯片的使用壽命。”

　　有幾個演講人還介紹了其他的關鍵工藝尺度問題：片外I/O帶寬并沒有隨著芯片內部性能的提高而增強。Bolsens認為：“3D的應用會在一定程度上解決互聯帶寬問題。但是，3D自己也會帶來新問題。我們會看到，2.5D越來越復雜，包括無源和內插存儲器等，實際上，快速2.5D并不會很快消失。全3D仍然還需要十幾年的時間才能成熟。”

　　而更保守的Burich警告說，除了技術問題，3D還面臨很多的業務關系問題。他警告說：“可能需要十幾年的時間才能解決這些問題。”

　　體系結構

　　多年以來，工藝技術和應用需求推動了FPGA體系結構實質性的變化。以前，工藝還只是專注于小晶體管的數量，應用則專注于膠合邏輯，FPGA大會在異構器件是否優于同構邏輯單元方面展開了激烈的爭論。今天，這方面的爭論看起來結束了，但是，演講人指出，實際并非如此。

　　Burich指出：“今天，FPGA內部只有40%是邏輯架構。”他解釋說，管芯的其他部分包括RAM、算術硬件、I/O、高速晶體管、協議引擎，有時候還有CPU內核和總線，以及一些支持電路等。Burich聲稱：“到2032年，所有的芯片都是異構的。”實際上，他認為，大規模IC體系結構是趨同的。最終，所有的看起來都是專用芯片系統（SoC），而有些芯片能夠部分重新配置，具有實質性的不同。

　　異構體系結構雖然很成功，但是有一個值得注意的例外。Bob Blainey是IBM匯編和下一代系統軟件特聘研究員，發表言論認為，他的世界是服務器計算，而不是硅片。他描述了未來，大部分服務器都內置在垂直3D IC管芯堆疊中，服務器本身只是堆疊的一個管芯，也會包括本地存儲器、互聯和規模很大的同構FPGA。

　　Blainey解釋說，這類FPGA將成為服務器的虛擬資源：一種受保護的虛擬架構，在這種架構上，系統軟件可以動態建立可共享的加速器。這類器件實際上匯集了大量可動態重新配置的邏輯門，由基于硬件的系統管理程序進行管理，對邏輯門的建立、拆除、共享和安全進行控制。

　　這兩類完全不同的體系結構之間也有其微妙之處。總體上，考慮SoC替代的設計人員，例如，移動設備和嵌入式計算領域的設計人員，傾向于認為未來的FPGA是關鍵位置具有邏輯架構的ASSP。認為在FPGA架構中直接實現軟件的設計人員傾向于未來是同構架構，具有很大的I/O帶寬。正如FPGA大會將要發表的論文所述，還有一些團隊嘗試怎樣實現硬核IP資源，例如，在可綜合處理陣列中實現存儲器模塊和DSP流水線，在軟件用戶中實現異構價值。

　　設計隱喻和工具

　　雖然在體系結構上有各種不同的觀點，但是在設計人員用于表達系統所使用的工具以及隱喻上卻有比較一致的看法。這種一致性的起點是，寄存器傳送級（RTL）作為表達系統的一種方法，已經不夠用了。Tabula總裁兼CTO Steve Teig認為：“當需要對FPGA編程時，RTL用起來很差。而C語言更差。雖然從串行轉向并行執行是非常底層的工作。Haskell等功能語言要好一些，但是，我認為λ-calculus仍然不是最好的抽象表達方式，這是一種大部分功能語言都以其為基礎的算術抽象語言。”

　　Blainey也同意這種看法。他預測，以后將廣泛的采用顯式并發語言，通過庫和編譯器將軟件轉換為FPGA結構。此外，會有很多功能語言編程精英來解決這類問題。Altera的Burich和Xilinx的Bolsens都認為，今后更多的設計會定位于顯式并行命令式語言，例如，OpenCL （圖2）等，他們都宣稱他們的公司正在從事這方面的工作。

　　
圖2. 將OpenCL代碼編譯到FPGA的并行結構中

　　其他演講人描述了完全不同的FPGA設計概念。Shep Siegel是Atomic Rules公司的創始人兼CTO，描述了一種可重用平臺，每一種FPGA實現都包括具有可動態重新定位功能的庫。Siegel認為：“還是需要RTL，但是，同步設計的概念只是一種隱喻。我們將擴展全局異步本地同步的（GALS）概念。而我們所關注的是彈性流水線和延時不敏感設計，我們使用時間戳來維持系統同步。”

　　Maxeler技術公司主席Michael Flynn和斯坦福教授Emeritus表達了相似的觀點。采用高性能計算加速器，Flynn的團隊將算法簡化為數據流圖形。Flynn解釋說：“他們采用Java描述圖形中的節點，建立非常長的流水線，復制到矢量處理陣列中，直到填滿硅片。”

　　Flynn說：“在20年內，所有技術都將是基于陣列的，只是受到軟件的限制。一個最大的難題是必須改變編程模型。軟件開發在過去20年的發展一直沒有處理好并行問題。”

　　Bolsens還介紹了系統軟件面臨的另一難題——在20年內將成為高級程序員的這一代會喜歡什么。我們已經過時了。如果您注意一下一個16年的老程序員，您會發現他們安心于異構的環境——Java、Perl、Python，等等。他們會選擇一種庫、應用程序或者他們能找到的一類代碼。

　　缺少的環節

　　幾名演講人還介紹了目前的技術以及2032未來技術之間一些未能解決的關鍵問題——從系統非常抽象的視圖到器件編程文件等。

　　Bolsens說：“必須通過研究填補軟件和硬件設計之間的空白。”Blainey還介紹了可綜合加速器的問題，他認為這是未來服務器堆疊中動態重新編程難以解決的問題。Flynn列舉數字說明了這一觀點：“今天，我們的布局布線需要運行數十個小時。那么，到2032年，是不是要運行一個月？供應商應該把這些工具置入到云中。”

　　Cheung的概念是通過常數可重新配置功能保持硅片工作，而且還假定了某類動態重新編譯功能，進一步發展了這種觀點。他認為：“我們將看到所有這些東西連接起來，這樣，有足夠的資源來管理重新配置問題。”他的觀點是，每一電子系統中都會有機械智能功能，云不再是服務器的遠程堆疊，而是擴展到互聯設備群中。這種觀點在支持泛在計算之前就有了，但是，Cheung認為處理亞2-nm技術必須要采用這種觀點。

　　總結

　　總之，研討發言人認為并不會出現對摩爾定律尺度發展革命性的偏離。但是，在怎樣處理大量的晶體管上存在爭議，怎樣解決尺度帶來的新問題。我們應該構建越來越專用的異構混合硬件功能模塊和可配置模塊？還是，研究大量邏輯門，提高本地邏輯門速率，開發大規模塊架構，以實現虛擬加速器？或者，需要可重新配置互聯專業知識來保持功能固定芯片不變，從而提高產量，在這一領域繼續發展？

　　我們會怎樣考慮我們正在建立的系統？幾乎可以肯定的是，RTL不會成為主要隱喻。但是，在過去，我們表達系統所使用的語言有一個不好的趨勢，總是按照剛畢業的這些人的喜好進行編程。我們能否構想，在ad-hoc腳本語言中將復雜系統作為任意混合異步任務來實現？軟件為主的團隊是否需要更簡潔的解決方案來設計2032年的系統？ 敬請關注。