軟硬件聯合仿真在確保高效云解決方案的質量、降低風險、節省時間和成本方面發揮著關鍵作用。達坦科技致力于打通云間壁壘、實現數據高效跨云訪問，為云上應用提供高性能安全存儲支持。在研發過程中，軟硬件聯合仿真顯得尤為重要。這一綜合仿真方法有助于驗證系統的一致性，分析和修復潛在故障，評估性能并優化資源分配。同時，它也用于評估系統的安全性，確保數據在跨云環境中得到充分的保護。我們將這一理論與實踐心得集結成： 軟硬件協同仿真系列 。本文是該系列的第一篇文章，著重介紹 原理及概述各部分的主要概念 。

01、為什么要仿真

在芯片設計領域，仿真驗證是保證設計正確的關鍵步驟。芯片生產成本高昂，因此需要在生產前盡可能對其進行仿真驗證以確保其功能和性能符合預期。另外，在芯片上運行的軟件也需要與芯片同步進行設計和測試，以縮短整個系統的生產和迭代周期，因此其載體只能是仿真的芯片。

02、硬件仿真方法

軟件仿真

傳統的仿真方法包括基于軟件的仿真和基于硬件的仿真。基于軟件的仿真利用軟件仿真電路邏輯。例如，QEMU可以模擬真實CPU的指令執行，兩者在執行同一條指令后寄存器發生同樣的變化，運行在CPU上的軟件不會分辨出其差別。這種使用高級語言編寫的模擬硬件行為的軟件一般也被用作硬件實現的參考模型，兩者可交叉驗證。

此外，描述硬件邏輯的RTL（Register Transfer Level）代碼也可以轉化高級軟件語言代碼，并最終生成可執行的仿真程序。這賦予了設計者在不需要真實硬件的情況下快速驗證硬件邏輯的能力。

硬件仿真

基于硬件的仿真則使用可編程的硬件平臺來模擬硬件邏輯。常見的如FPGA(Field Programmable Gate Array)板卡，其內部為可編程的硬件結構，允許設計者將電路邏輯燒錄進去，成為一個接近真實芯片的硬件原型，可實時模擬并觀察硬件邏輯的運行狀態。

相比于基于軟件的仿真，基于硬件的仿真速度更快，可以提供更接近真實硬件的性能，但在調試和修改時的靈活性較低。其能模擬的硬件規模受自身規模限制，仿真成本隨規模上升速度也遠高于軟件方法。

03、軟硬件協同仿真

軟硬件協同仿真指同時模擬硬件和軟件集成在一起的整個系統。其中硬件的仿真可能是在硬件仿真器中，或由軟件模擬。軟件模擬又可分為直接由RTL轉譯，或是另外開發的事務級參考模型，亦或是兩者的結合。

例如，當我們仿真驗證一塊采用PCIe接口的網卡時，在使用軟件仿真時，可以將PCIe部分的硬件邏輯由軟件模型代替，將網卡的RTL代碼轉譯為可執行程序進行仿真，再將兩者結合后接入到運行網卡驅動程序的QEMU虛擬機中，即完成了整個系統的仿真。

以上例子中，PCIe部分不是我們的驗證重點，因此用事務級軟件模型仿真。由于省略了對具體電路行為的仿真，提高了仿真抽象水平，軟件模型相較由RTL轉譯的仿真程序執行速度更快。使用硬件仿真時，PCIe部分邏輯可由硬核實現，網卡邏輯燒錄在可編程門陣列中，以提高仿真速度，降低仿真器占用。QEMU中的應用軟件和驅動程序可不感知以上硬件仿真的具體實現。

軟硬件協同仿真試圖結合軟件仿真和硬件仿真，使開發者可以同時驗證和調試系統的軟件和硬件部分。對硬件邏輯實現復雜的、非驗證重點的部分使用事務級模型仿真，對性能有要求或需要重點驗證的部分則采用基于硬件的仿真，亦可結合對成本和工期的要求進行配置。通過這種混合仿真的方式，設計者可以以較低的成本和較高的性能驗證整個系統。

04、主要組成部分

軟硬件協同仿真涉及多個關鍵組件和工具，其中最核心的有QEMU、SystemC/TLM、RTL Simulation和Bridge。在此簡要介紹一下組件的基本概念和它們之間的關系。

QEMU

QEMU是一個廣泛應用的開源機器模擬器和虛擬化工具。QEMU能夠模擬整個系統級別的操作，如模擬一臺計算機，包括硬件部件操作系統以及驅動等。其可以模擬任意硬件，或為硬件提供一個真實的軟件運行環境。

SystemC/TLM

SystemC是用于系統級建模的開源C++庫，而TLM（Transaction Level Modeling）是一個在SystemC環境下描述與仿真硬件行為的模型。相比于傳統的RTL設計，TLM能夠更高層次地描述硬件行為，從而提供更快的仿真速度。使用SystemC/TLM構建的模型通常作為“膠水”連接QEMU和RTL。例如，在上述網卡仿真例子中，PCIe部分由一個事務級的TLM模型描述，兩端分別連接軟件和仿真的硬件。

RTL Simulation

RTL仿真可以基于軟件或硬件進行。軟件如Verilator，一個開源的Verilog仿真器，它可以將Verilog代碼轉換為C++模型，然后通過C++進行快速仿真。硬件如FPGA，其中包含可編程的硬件邏輯，可用于仿真硬件原型。

Bridge

要將軟件與硬件集成，還需要各類橋接器連接軟硬件邏輯。例如TLM到PCIe等各類硬件接口到軟件接口互聯橋。這部分需要根據具體的軟硬件平臺開發，或使用開源項目LibSystemCTLM-SoC提供的常見接口轉換橋。

下圖展示了一種組件之間的連接關系。假設我們模擬一個PCIe設備（如網卡），QEMU模擬了一臺計算機，承載操作系統和設備驅動程序。TLM模型和RTL仿真共同實現了設備邏輯，并通過Socket連接到QEMU中，表現為一個PCIe設備。

下圖展示了TLM級仿真和RTL級仿真的橋接細節。其中TLM GP（Generic Payload）指一個一般的總線讀/寫操作。Bridge的作用就是將TLM事務級的操作轉化為RTL級的信號。例如，TLM的一個讀事務可能會被轉換為在RTL級別的一個地址信號、一個讀使能信號等。由于TLM模型通常是與時間無關的或粗粒度的，所以在轉換為RTL信號時，橋必須考慮時序問題。這可能涉及到模型之間的時間同步，以確保所有事務和信號都在正確的模擬時間內發生。

05、仿真案例

下面以一個例子介紹SystemC/TLM軟件模型與仿真的硬件設備的對接流程和實現原理。

在Xilinx的libsystemctlm-soc倉庫中包含一個AXI4從設備與SystemC/TLM模型交互的樣例程序（example-rtl-axi4）。其中axifull_dev_s00_AXI.v是由 Xilinx IP Integrator自動生成的Verilog模塊，其功能是一塊可通過AXI4總線讀寫的存儲器。axifull_dev.v對其進行了一層封裝，并預留了用戶增加額外邏輯的空間。以上即為硬件部分。

在http://example-rtl-axi4.cc中描述了TLM模型與AXI設備的連接和交互邏輯。主要包括將axifull_dev設備實例化為DUT（Device Under Test），并通過軟件生成的仿真測試激勵，對硬件進行讀寫操作測試。

如下是http://example-rtl-axi4.cc部分代碼。首先是通過TrafficDesc transactions定義了一組要在仿真環境中執行的事務，分別是寫，讀，以及期望讀到的值。TrafficDesc在此用于簡化生成TLM GP的操作。激勵生成器 (TLMTrafficGenerator tg) 根據transactions對事務的描述生成TLM GP。再通過TLM到AXI的橋接器 (tlm2axi_bridge bridge) 被轉換為AXI信號，最后由被測設備 (Vaxifull_dev dut) 處理。

TrafficDesc transactions(merge({
    // 寫數據到地址8
    Write(8, DATA(0x1, 0x2, 0x3, 0x4)),
    // 讀回并判斷讀到的是否是預期數據
    Read(8, 4),
    Expect(DATA(0x1, 0x2, 0x3, 0x4), 4)
}));
         
SC_MODULE(Top)
{
    sc_clock clk;
    sc_signal

TLM GP定義了一個總線讀寫事務的抽象，包括讀寫命令、響應狀態、地址和數據相關信息。以下截取了定義的一部分，完整代碼可見tlm_gp.h。當然，TLM GP只包含最一般的信息，沒有攜帶與AXI協議相關的一些具體概念。為了建模此類與硬件總線協議相關的具體行為，庫中還包含了可選的拓展屬性Generic Attributes，用以更細致地建模，在此就不展開了。

class SC_API tlm_generic_payload {      
···           
private:
    /* --------------------------------------------------------------------- */
    /* Generic Payload attributes:                                           */
    /* --------------------------------------------------------------------- */
    /* - m_command         : Type of transaction. Three values supported:    */
    /*                       - TLM_WRITE_COMMAND                             */
    /*                       - TLM_READ_COMMAND                              */
    /*                       - TLM_IGNORE_COMMAND                            */
    /* - m_address         : Transaction base address (byte-addressing).     */
    /* - m_data            : When m_command = TLM_WRITE_COMMAND contains a   */
    /*                       pointer to the data to be written in the target.*/
    /*                       When m_command = TLM_READ_COMMAND contains a    */
    /*                       pointer where to copy the data read from the    */
    /*                       target.                                         */
    /* - m_length          : Total number of bytes of the transaction.       */
    /* - m_response_status : This attribute indicates whether an error has   */
    /*                       occurred during the transaction.                */
    sc_dt::uint64        m_address;
    tlm_command          m_command;
    unsigned char*       m_data;
    unsigned int         m_length;
    tlm_response_status  m_response_status;
    ···
}

從TLM GP到AXI信號的轉換邏輯在Bridge中完成，具體實現在文件tlm2axi_bridge.h中。概括其內容，就是根據總線協議手冊，將TLM GP對一個事務的抽象描述翻譯為一個時間序列上硬件信號線上的高低電平。以寫數據的實現為例，如下是截取的一個代碼片段，描述的內容是將wready位置高，等待wvalid變為高，遇到reset信號則需要等到其被釋放，然后是向一組wdata信號線填充數據位等等。

void write_data_phase()
{
    while (true) {
        ···
        wready.write(true);
        wait_abort_on_reset(wvalid);
        if (reset_asserted()) {
            wait_for_reset_release();
            continue;
        }
        ···
    }
    wt- >FillData(wdata, wstrb);
    ···
}

在軟件仿真環境中，如SystemC和Verilator，軟件定義的信號狀態會周期性地更新同步到仿真的硬件描述語言中的信號線上。由于硬件被仿真器轉譯為軟件，因此信號間的同步實質是軟件變量間的賦值。

在硬件仿真環境下，軟件定義的信號到硬件信號的映射需要更多橋接工作。例如當采用PCIe接口的FPGA進行仿真時，上述DUT運行在FPGA上，TLM模型在CPU中運行，PCIe作為通信媒介。TLM模型需要通過PCIe，間接控制FPGA上的AXI設備。這中間涉及到對PCIe設備的控制，以及PCIe到AXI的映射等橋接工作，libsystemctlm-soc也封裝了此硬件橋，如tlm2axi_hw_bridge。在這些橋接工具庫的幫助下，開發者可以方便地在純軟件和軟硬件混合的仿真平臺之間切換，而不用對程序做大幅修改。

以上例子只是簡單地展示了SystemC/TLM部分與硬件的連接方法，并使用兩個簡單的事務對硬件進行了測試。在此基礎上，我們可以使用軟件高級語言如C++模擬任意硬件行為，構建高抽象水平的模型，并通過SystemC提供的工具庫賦予模型與硬件邏輯交互的能力。軟件模型又可以通過Socket接入到QEMU，由QEMU中的應用軟件生成測試激勵，以完成從應用、驅動、到設備的整個軟硬件系統的集成測試。

06、總結

本文介紹了軟硬件協同仿真的原因，概念和方法。通過結合軟硬件仿真，TLM級仿真和RTL級仿真的優勢，降低仿真成本，提高仿真速度。使得開發者可以在流片前驗證從硬件到軟件的整個系統，確保軟硬件設計的正確性和性能滿足預期要求，縮短迭代周期。

軟硬件協同仿真的技術鏈條長，涉及多個技術組件和工具，混合了不同抽象級別的軟硬件系統。本文受篇幅所限，只概述了其主要組成部分，后續在“軟硬件協同仿真”系列里將結合實例，為大家分享鏈路每個環節背后的實現原理。