作者：Steve Leibson, 賽靈思戰略營銷與業務規劃總監

我上篇博文“我們能相信HLS嗎？Brian Bailey想知道，也許你也想知道”，在LinkedIn網站各種FPGA相關的群組中引發了非比尋常的關注和討論。

這是LinkedIn網站SOC討論區中Joel Jamais的回復：
“事實上，我去年曾經被借調了幾個月，去參加一個HLS項目，這個項目有兩家有競爭關系的HLS CAD工具提供商，目標是一些已經完成RTL編碼的IP模塊。它們面臨的挑戰是優化面積、速度以及功耗。參賽選手是：
1: HLS工具提供商1號
2: HLS 工具提供商2號
3: 手工編寫RTL代碼

當時我在這個實驗中的角色是一名工程顧問，工作僅限于設置和運行PLDRC（linting）、綜合、靜態時序分析、PTPX等工具，而RTL代碼是由這兩個HLS工具來輸出，每天，這兩個在幕后工作的HLS工具都會輸出一次或者多次迭代的RTL代碼。每一次迭代都會解決一些linting錯誤，或者是減小面積，或者是解決時序違例，或者是降低功耗。這個工作是不包括DFT的。經過兩個月，初步結論是手工編寫的RTL代碼是最優的，然后是兩個HLS工具其中的一個。隨后，我被派到另外一個項目，因此失去了繼續對HLS工具評頭論足的機會。

考慮到在這個實驗中我的角色的局限性， 我覺得，要想和有經驗的RTL設計人員手工編寫的代碼去競爭，
HLS工具還有一些路要走，特別是那些控制邏輯多于數據通路邏輯的設計。換句話說，如果數據通路邏輯，比如一個DSP功能，已經是用C語言（或C++，或SystemC）實現編碼的，那么完全有理由去使用這些HLS工具，因為，通過HLS工具轉換得到的RTL代碼，只需要再做一些RTL增量開發，去滿足linting規則檢查，實現面積、時序、功耗的優化，以及插入DFT。”

還是LinkedIn網站SOC討論區，Brian Logsdon的回復：
“每一個正常的人在發布設計之前，都會使用HLS、GLS、STA、FEC以及PRA。要想交付的方案工作起來更有保障，唯一的方法就是使用上述所有的工具?！?/p>

這是LinkedIn網站上ASIC、FPGA和SoC工程師群組的ASIC討論區，Doug Walby的答復：
“我正在構建一個驗證用例去驗證一個由HLS工具產生的設計。如果你喜歡象調試門級電路那樣去調試RTL，那么HLS非常適合你。如果你更喜歡RTL代碼有一個更實用的外表，并且喜歡在手工編寫的RTL代碼這樣的抽象層次上進行調試，那么你很可能就會失望。如果你想要盲目相信自己的RTL代碼沒有缺陷，不經過RTL驗證就發布，那么HLS可能會對你有幫助，這樣可以避免出現另外一個人在使用RTL代碼并行開發的同時，無法發現C代碼中任何錯誤的情況?！?/p>

LinkedIn網站FPGA群組，Phil Duff的回復：
“我們在HLS上有著第一手的使用經驗，我們正處于拓展產品的過程中，它是一個商業/工業的通信系統。然而，在使用HLS來獲取高質量的結果時，確實是有一點不可思議的魔法在里面，我認為我們已經得到它了。對于熟練的使用人員來說，這類工具有許多有吸引力的地方，包括工作效率方面的優勢?！?/p>

還是LinkedIn網站FPGA群組，Ed Henciak的回復：
“我確實喜歡我用HLS綜合過的代碼邏輯（相對比較簡單的），這個夏天，我將要嘗試一些更復雜的代碼。

在使用HLS時，我卡在了一個地方，就是要象AXI總線主/從設備那樣去表達事物。雖然我沒有主動去尋找參考設計，但我并不覺得這有多簡單。我可以輕而易舉地使用HDL編寫一個新的主/從控制器。。。用C語言來寫看起來就相當笨拙。可悲的是，用HDL來寫就意味著我必須對這個設計進行仿真，這樣跟在我的PC機上直接運行可執行文件進行“仿真“相比，在效率上就會低一些。

我多了很多圖像處理的工作。。。我總是和幀緩存以及PCIe邏輯打交道，通常情況下，這些邏輯都是基于AXI總線或者AXI-S總線接口。

在仿真圖像處理邏輯時，需要在仿真環境中提供相當大的數據量來一起工作，這是非常折磨人的事情。HLS就可以允許有一些真實的、有趣味性的驗證方法。

重復一下，我在HLS方面相對來說還是一個新手，所以，如果我的描述中漏掉了一些顯而易見的事情，那么請原諒我吧。多年的FPGA HDL的設計經驗會遮蔽一個人的視野 :-)。”

Sharad Sinha對Henciak的評論的回復：

“用C語言來編寫象AXI這樣的接口確實是非常困難的，因為C語言沒有任何時序的概念。這也就是為什么在最新的Vivado-HLS（它的前身是AutoESL）版本中有一些選項，可以使用AXI等接口對C語言產生的RTL代碼進行一層封裝。我還沒有對它進行測試，所以我不能評論它有多么好，可以試著去閱讀這篇文章的第7頁：（在Zynq-7000 All Programmable SoC中，使用Vivado HLS實現浮點矩陣乘法加速器）

同時，HLS工具是假定使用人員具備硬件設計基礎知識的。這些工具有許多編譯指示和指令，使用人員可以用來指引工具進行工作，但是，如果一個人不能理解這些指令怎么對硬件設計產生影響，那么他就無法使用這么多的指令?！?/p>

另一個評論來自于Phil Duff：
“有一些評論恰好反映了我最初的擔憂，我們對事情如何實現缺乏必要的理解。作為一個非常有經驗的HDL編碼人員，在RTL層次上編寫代碼，HLS工具的權衡是很有意思的，下面是HLS的一些主要的賣點：
1）'C'的行為仿真非常快，盡管有些結構也會非常慢。在共享存儲器（Zynq）中實現一個32MB定點精度陣列無疑是讓人絕望的，但int類型是易于實現的，在硬件上，這僅僅是個入門設計。

2）一旦你掌握了AXI總線，那它幾乎就是微不足道的。你會碰到一些帶有用戶自定義數據結構的數據流、同軟件之間的接口（需要編寫底層驅動）、共享存儲器的DMA訪問，等等。

3）RTL編碼人員知道，“白板”的數據通道是非常容易實現的，有些棘手的是控制狀態機，使它的所有功能都能正常工作。HLS能夠編寫狀態機，可以為你節省大量的時間。只需要改變幾行代碼或者一些編譯指示，架構就會發生非常大的變化，可以在資源、延遲以及吞吐率方面進行比較多的權衡。

4）RTL編碼人員對可能的實現結果以及不同方法所產生的結果能有一個很好的理解。

5）能為Linux等編寫底層驅動。

6）準備好IP模塊，集成到IPI。

雖然如此，這里也還有一些困難，要想熟練掌握這個工具，能通過編譯指示、代碼布局、使用任意精度類型、接口數據結構等等來充分利用這個工具，我們需要進行專業化的培訓。HLS需要有一個投入，才能給我們最好的回報，我想我們都不會停止學習。

我們能相信HLS嗎？我們已經得到了我們開始想要得到的答案，并且感覺到我們正處于一個正確的位置上。當然，我們也做出了一些妥協，但這就是工程設計。最大的問題是工具的一個長期的演進，已經說過，我們在體系架構方面有豐富的知識，因此，如果有必要，我們可以使用一個不同的工具流程來重新實現架構。

原文鏈接：

? Copyright 2014 Xilinx Inc
如需轉載，請注明出處