本系列我想深入探尋 AXI4 總線。不過事情總是這樣，不能我說想深入就深入。當前我對 AXI總線的理解尚談不上深入。但我希望通過一系列文章，讓讀者能和我一起深入探尋 AXI4。

歡迎來到深入 AXI4 總線的實戰篇，系列第二篇文章中，我們將首先了解調用 AXI VIP 產生激勵與響應的方法，并完成一個小目標：實現三種情況下的握手信號。

關于平臺移植

本文的實戰在第一篇的示例工程上，新建 tb 來實現我們的功能。新建 tb 中的邏輯由 demo tb 的內容搬運簡化而來。

本來計劃新建一個工程，但是閱讀 PG267 （IP 核的產品文檔）發現，當前 Vivado 對于該 IP 的支持還比較弱，需要將 IP 的實例名以及層次路徑硬編碼至 tb 中，如果新建工程還比較麻煩。所以本文暫時還是在 example 的基礎上展開 。

想要重新搭建工程的讀者請注意閱讀 demo tb 開頭的說明，或者 PG267 第六章中的內容。

本文的場景為主機與從機之間通過 Pass-through （以后叫 ta 中間機？）進行通信。從機選用 mem 模式，有自己的存儲模型，即使用 mem_stimulus.sv 作為激勵。關于存儲模型，我們將在后續的文章中討論。

我們的改動在于主機的激勵部分，以原先的 mst_stimulus.sv 為基礎，構建我們自己的主機激勵，改動后的 testbench 結構如下圖所示。

是的，新的激勵加上了 headbig 字段，這來自于 深入 AXI4 總線 系列文章的英文名：Headbig AXI4。

VIP API 基本調用方式

PG 文檔中，Xilinx 表示 VIP 基于 SystemVerilog 語言開發，同時在 API 的設計上，命名與數據結構的設計均參考了 UVM 框架，便于 VIP 在驗證系統中的集成。由于本文的重點不在于 UVM 或者 API 的設計，因此僅跟著 demo 以及 PG 中的 API 調用流程過一遍。

主機 master

首先來看主機，定義于 axi_vip_master_mst_stimulus.sv 中

為主機 master ip 創建一個 agent 對象，傳入 master ip 的層級路徑，后續通過該 agent 控制主機 ip

agent = new("master vip agent",DUT.ex_design.axi_vip_mst.inst.IF);

通過 agent 啟動主機

agent.start_master();

在 fork ...join 并發塊中同時發出主機的讀寫傳輸事務。

fork
 begin
  //調用寫傳輸事務 API
 end
 
 begin
  //調用讀傳輸事務 API
 end
join

產生兩者的 API 結構相似，我們以寫傳輸事務為例。例程中依次使用了 3 種 API ，分別產生

完全隨機化的寫傳輸事務

multiple_write_transaction_full_rand ("single write",1);

定制化的寫傳輸事務

single_write_transaction_api("single write with api",
                   .id(mtestWID),
                   .addr(mtestWADDR),
                   .len(mtestWBurstLength), 
                   .size(mtestWDataSize),
                   .burst(mtestWBurstType),
                   .wuser(mtestWUSER),
                   .awuser(mtestAWUSER), 
                   .data(mtestWData)
                   );

部分隨機化的寫傳輸事務

multiple_write_transaction_partial_rand(相關參數);

我們常說，不想知道 API 函數之下發生了什么的程序員不是好程序員，IC 工程師同樣如是。以較簡單的定制化寫傳輸事務函數為例，所謂函數實質上是一個 sv task，以下是 task 中的主要內容：

  axi_transaction                wr_trans;
  wr_trans = agent.wr_driver.create_transaction(name);
  wr_trans.set_write_cmd(addr,burst,id,len,size);
  wr_trans.set_prot(prot);
  //...
  wr_trans.set_data_block(data);
  agent.wr_driver.send(wr_trans); 

首先聲明一個 axi 傳輸事務對象，然后在主機 ip 的 agent 下建立傳輸事務。

通過 API 函數設定寫命令信息，設定傳輸屬性以及待傳輸的數據塊。數據塊的數據類型為

bit [4 * 1024 * 8 - 1:0]

從機 slave

接下來，我們看一下從機的相關流程，定義于 axi_vip_master_mem_stimulus.sv 中。

同樣為從機創建并啟動相應 agent，此處與主機相似不表。

在 demo 中構造了一個虛擬數據作為后續對主機讀數據的回應，因為本文的主要工作是得到握手信息的波形，因此并不會實際存儲主機寫入的數據，而是在主機讀取任意地址時，返回這個虛擬數據。

最后，從機調用 API 產生 wready 信號應答

  task user_gen_wready();
   axi_ready_gen              wready_gen;
   wready_gen = agent.wr_driver.create_ready("wready");
   wready_gen.set_ready_policy(XIL_AXI_READY_GEN_OSC);
   wready_gen.set_low_time(1);
   wready_gen.set_high_time(2);
   agent.wr_driver.send_wready(wready_gen);
  endtask

此處表示 wready 信號在從機空閑時周期性生成，有效時間為 2/3，我們可以在后續的波形中看到。

握手波形

我們對主機的激勵代碼進行修改，僅保留單次定制化的讀寫傳輸事務，地址為 0x0，突發長度為 0。在波形中我們得到了三種情況下的握手信號。

（1）VALID 信號等待 READY 信號

在 tb 中主機并行地啟動讀寫傳輸事務，AR/W VALID 同時置高，在等待從機給出 READY 信號后完成地址與控制信號的傳輸，此時地址為 0x0.

(2)READY 信號等待 VALID 信號

主機在發出讀傳輸事務后，置高 RREADY 信號等待接收從機返回的讀數據。在從機置高 RVALID 后，讀傳輸事務完成。

(3)READY 與 VALID 信號同時置起

在設置從機的 READY 信號類型時，我們設置為周期性置高 READY，從下圖中可以看到，READY 信號在送出 2 個周期高電平后置低 1 個周期。

在這個場景中，寫數據通道中的 WREADY 信號正好與 WVALID 信號同時置起，解鎖了最后三種握手姿勢中的最后一種，OK 本文實戰篇收工了。

結語

本文首先介紹了 AXI VIP 中產生傳輸事務的基本方法。基于 demo 修改了一個簡單純粹的例子，并基于這個例子觀察到了握手信號。