為了盡快把新產(chǎn)品推向市場，數(shù)字系統(tǒng)的設計者需要考慮如何加速設計開發(fā)的周期。設計加速主要可以從“設計的重用”和“抽象層級的提升”這兩個方面來考慮。Xilinx 推出的 Vivado HLS 工具可以直接使用C、C++或 System C 來對 Xilinx 系列的 FPGA 進行編程，從而提高抽象的層級，大大減少了使用傳統(tǒng) RTL描述進行 FPGA 開發(fā)所需的時間。

一、高層綜合簡介

如圖 1.1.1 所示，F(xiàn)PGA 設計中從底層向上一共存在著四種抽象層級，依次為：結構性的、RTL、行為性的和高層。其中最底層的抽象(結構性的)涉及到對底層硬件單元直接的例化，比如邏輯門，甚至是更底層的 LUT 或者觸發(fā)器。設計者更常用的是在“寄存器傳輸級(Register Transfer Level，RTL)” 進行設計，這個層級的抽象隱藏了底層的細節(jié)，是在描述寄存器和寄存器之間可執(zhí)行的操作。更上層的“行為性的”描述是對電路的算法描述，也就是描述電路表現(xiàn)出什么樣的功能(行為)，而不是描述每個寄存器該如何進行操作。

前面介紹的幾種抽象層級都是在使用硬件描述語言 HDL 進行設計，可以看出，隨著抽象層級的提升，設計最終在硬件上實現(xiàn)的細節(jié)逐漸被弱化。而本章重點介紹的“高層”設計方法則直接使用高級語言，如C/C++進行設計，然后由 Vivado HLS 編譯器將 C 代碼綜合成 HDL 描述，最后再進行邏輯綜合得到網(wǎng)表，這個網(wǎng)表最終會被映射到具體的 FPGA 器件上。

就像 C 語言或者其他高級語言針對不同的處理器架構有著不同的編譯器，Xilinx Vivado High-Level Synthesis(高層綜合，HLS)工具同樣是一種編譯器，只不過它是用來將 C 或者 C++程序部署到 FPGA 上，而不是部署到傳統(tǒng)的處理器上。

在 Vivado HLS 中可以使用三種語言進行設計開發(fā)，分別是 C、C++ 和 SystemC。

二、HLS 設計流程

Vivado HLS 的功能簡單地來說就是把 C、C++ 或 SystemC 的設計轉換成 RTL 實現(xiàn)，然后就可以在Xilinx FPGA 或 Zynq 芯片的可編程邏輯中綜合并實現(xiàn)了。需要注意的是，這里我們說的使用 C/C++完成的設計與運行在處理器(ZYNQ 中的 ARM 處理器或 MicroBlaze 軟核處理器)中的軟件代碼是截然不同的。在 HLS 中，所有的 C 設計都是要在可編程邏輯中實現(xiàn)的，也就是說，我們?nèi)匀皇窃谶M行硬件設計，只不過使用的不再是硬件描述語言。

使用 Vivado HLS 進行設計的流程如下圖所示：

HLS 設計的主要輸入是一個 C/C++/SystemC 設計，以及一個基于 C 的測試集(TestBench)。我們首先要知道 C 語言的本質(zhì)就是函數(shù)，那么這個測試集就是用于驗證 C 設計中的函數(shù)，驗證過程需要一個“黃金參考”。這個“黃金參考”類似于一個標準答案，用來和 C 設計中函數(shù)所產(chǎn)生的輸出做比對。

在對 HLS 設計進行綜合之前，我們要先對其進行“功能性驗證”，也就是 C 仿真，其目的是驗證 HLS 輸入的 C 代碼的功能是否正確。驗證的方式就是在 TestBench 中調(diào)用 C 設計的函數(shù)，然后將其輸出與“黃金參考”進行比對，如果與黃金參考有差異就需要先對 C 設計進行修改調(diào)試。

接下來就是對設計進行高層綜合，即 HLS 過程本身。該過程涉及到分析和處理基于 C 的代碼，加上用戶所給出的指令和約束，來創(chuàng)建 RTL 描述。高層綜合結束后會產(chǎn)生一組輸出文件，包括以 Veilog 或者VHDL 語言編寫的 RTL 設計文件。

綜合過程結束后得到的 RTL 模型，可以在 Vivado HLS 中進行 C/RTL 協(xié)同仿真，來進一步驗證綜合得到的 RTL 設計的正確性。在這個過程中 Vivao HLS 會自動產(chǎn)生一個測試集為 RTL 設計提供輸入，然后拿它的輸出與預期的值做比對。C 功能性驗證和 C/RTL 協(xié)同仿真的區(qū)別如下圖所示：

在圖 1.2.2 左側的功能性驗證(C 仿真)中，原始測試集是用戶輸入的測試文件 TestBench。而右側的C/RTL 協(xié)同仿真所需的 RTL 測試集是由 Vivado HLS 自動產(chǎn)生的，這樣就不再需要人工創(chuàng)建了，所產(chǎn)生的測試集包括了原始測試集和被測 RTL 模塊之間的數(shù)據(jù)傳遞。

除了對功能進行驗證，我們還要評估 RTL 設計的實現(xiàn)和性能。比如，在 FPGA 中所需的資源的數(shù)量，設計的延遲、所支持的最高時鐘頻率等是否滿足要求。如果不滿足要求，那么就需要設計者通過修改指令和約束，然后再次進行高層綜合，如圖 1.2.1 中右側的回路所示。一個設計可能要做多次 HLS 設計迭代，來找到“最佳 ”的解決方案。如果有必要，設計者也可以返回修改 C 設計代碼，然后從頭開始重新對設計進行驗證。

在設計被驗證了之后，而且實現(xiàn)也滿足了期望的設計目標，那么就可以集成進更大的系統(tǒng)里了。我們可以直接使用 HLS 過程所產(chǎn)生的 RTL 文件(即 VHDL 或 Verilog 代碼)，更方便的做法是使用 Vivado HLS 的 IP 打包功能。對 Vivado HLS 所產(chǎn)生的輸出打包意味著 HLS 設計能夠以 IP 核的形式引入其他 Xilinx 工具中，比如 Vivado 中的 IP 集成器。這兩種類型的輸出如下圖所示：

三、 接口綜合

在做 HLS 的時候，設計者需要分析設計的兩個主要方面：

設計的接口，也就是它的頂層連接;

設計的功能，也就是它所實現(xiàn)的算法;

我們給出一個 HLS 設計中接口和功能的概念圖，如圖 1.3.1 所示。

在上圖中，兩端的綠色區(qū)域表示設計的輸入和輸出接口，其中展示了部分接口類型，如 RAM 接口、FIFO 接口，以及總線類型的接口等。這些接口可以是工具從代碼中通過接口綜合(Interface Synthesis)得到的，也可以由設計者手動指定具體的接口類型。

圖中間黃色的區(qū)域表示 HLS 設計具體能夠實現(xiàn)的功能，對于不同的應用，其功能也各不相同。在 Vivado HLS 設計中，功能是從輸入的代碼中，經(jīng)過算法綜合(Algorithm Synthesis)的過程得到的。

在這里我們先簡單介紹一下接口綜合。顧名思義，Interface Synthesis 指的是 HLS 設計中對接口的綜合，綜合出來的接口能夠與系統(tǒng)中的其他模塊通信，還有可能需要與系統(tǒng)中的處理器進行通信。

這里接口的概念既包括端口(port)，也包含所使用的協(xié)議。所有端口的細節(jié)(如類型、位寬和方向)是從 C/C++ 文件中頂層函數(shù)的參數(shù)和返回值里推斷出來的;而協(xié)議是從端口的表現(xiàn)(行為)推斷出來的。比如，最簡單的接口可以是一條 1 比特的線(wire)，而更復雜的接口，可能要用總線或 RAM 接口。接口綜合能夠推斷出來的接口類型包括：線、寄存器、單向和雙向握手信號、FIFO、存儲器和總線等。

下面我們給出一個簡單的 C 設計的頂層函數(shù)，函數(shù)名為 find_average_of_best_X()，其參數(shù)如下圖所示：

圖 1.3.2 中函數(shù)內(nèi)部工作的詳細情況無關緊要，不過每個參數(shù)的讀/寫操作將決定綜合出來的端口的方向。這個函數(shù)定義包含三個參數(shù)，數(shù)組“sample”和整數(shù)“X”是函數(shù)的輸入，而 average 作為函數(shù)的輸出。因此，簡單來說，這三個函數(shù)參數(shù)要被 HLS 轉換成兩個輸入接口和一個輸出接口，如下圖所示：

需要注意的是，圖 1.3.3 只是一個簡化了的接口示意圖。根據(jù)所用的協(xié)議，這些接口可能包括數(shù)據(jù)端口自身以外的控制輸入或輸出，如下圖所示：

圖 1.3.4 是函數(shù) find_average_of_best_X()經(jīng) HLS 綜合出來的完整的 RTL 模塊的接口圖。從圖中可以看到由函數(shù)的三個參數(shù)所綜合出來的接口分別擁有了各自的協(xié)議，如 ap_memory 協(xié)議、ap_none 協(xié)議和 ap_vld協(xié)議。同時模塊還多出來了一些端口，如 ap_clk 和 ap_rst 等，它們使用的是 ap_ctrl_hs 協(xié)議。這些協(xié)議決定了相應的接口是如何與系統(tǒng)中其他模塊進行交互的，至于各協(xié)議具體的含義以及如何為接口選擇其協(xié)議，我們將在后續(xù)的章節(jié)中介紹。

四、算法綜合

算法綜合關注的是設計的功能，即設計所期望的行為，它是由輸入的 C 設計所描述的。算法綜合從代碼中推出各種運算操作，然后轉換成一組 RTL 語句。

算法綜合包括三個主要階段，依次是：

解析出數(shù)據(jù)通路和控制電路;

調(diào)度和綁定;

優(yōu)化;

解析出數(shù)據(jù)通路和控制電路

HLS 的第一個階段是分析 C/C++/SystemC 代碼，并且解釋所需的功能。Vivado HLS 從以下幾個方面分析程序：邏輯和算法的運算、條件語句和分支、數(shù)組運算和循環(huán)等。

所產(chǎn)生的實現(xiàn)會具有一個數(shù)據(jù)通路元件，一般還會有一個控制元件。需要澄清的是，這里的“數(shù)據(jù)通路”處理指的是在數(shù)據(jù)樣本上作的運算，而“控制”是需要協(xié)同數(shù)據(jù)流處理所需的電路。算法的本質(zhì)定義出數(shù)據(jù)通路和控制元件，設計者可以在 HLS 中采取專門的步驟來最小化控制元件的復雜度。

調(diào)度和綁定

HLS 是由兩個主要過程組成的：調(diào)度(Scheduling)和綁定(Binding)。它們是交替進行的，彼此互相影響，如下圖所示：

調(diào)度是把由 C 代碼解釋得到的 RTL 語句翻譯成一組運算，每個運算都關聯(lián)著一定的執(zhí)行時間，以時鐘周期為單位。這個階段所作的決策，受時鐘頻率和不確定度、目標芯片的技術和用戶所施加的指令所影響。

綁定是調(diào)度好了的運算和目標芯片上的實際資源聯(lián)系起來的過程。這些資源的功能和時序特征可能會影響調(diào)度，因此綁定信息會反饋給調(diào)度過程。比如使用 DSP48x 資源就表明關鍵路徑比采用邏輯資源的方案要短。

優(yōu)化

約束 ：設計者可以對設計的某些指標加以限制。比如，可以指定最低的時鐘周期。這樣就能確保實現(xiàn)結果能夠滿足要集成進去的系統(tǒng)的要求。類似的，設計者可以選擇約束資源的利用情況或其他的指標，從而優(yōu)化應用的設計。

指令：設計者可以通過指令對 RTL 的實現(xiàn)參數(shù)施加更具體的影響。有各種類型的指令，分別映射在代碼的某些特征上，比如讓設計者可以指定 HLS 引擎如何處理 C 代碼中識別出來的循環(huán)或數(shù)組，或是某個特定運算的延遲。這能導致 RTL 輸出的巨大改變。因此，具有了指令的知識，設計者就可以根據(jù)應用的需求來做優(yōu)化了。

五、 HLS 庫

Vivado HLS 中包含了一系列的 C 庫(包括 C 和 C++)，方便對一些常用的硬件結構或功能使用 C/C++進行建模，并且能夠綜合成 RTL。在 Vivado HLS 中提供的 C 庫有下面幾種類型：

1、任意精度數(shù)據(jù)類型庫

2、HLS Stream 庫

3、HLS 數(shù)學庫

4、HLS 視頻庫

5、HLS IP 庫

6、HLS 線性代數(shù)庫

在 HLS 設計中調(diào)用庫中的函數(shù)可以大大提高開發(fā)效率。