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

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

關于平臺移植

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

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

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

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

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

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

VIP API 基本調用方式

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

主機 master

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

為主機 master ip 創(chuàng)建一個 agent 對象，傳入 master ip 的層級路徑，后續(xù)通過該 agent 控制主機 ip

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

通過 agent 啟動主機

agent.start_master();

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

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

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

完全隨機化的寫傳輸事務

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(相關參數(shù));

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

  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 函數(shù)設定寫命令信息，設定傳輸屬性以及待傳輸?shù)臄?shù)據(jù)塊。數(shù)據(jù)塊的數(shù)據(jù)類型為

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

從機 slave

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

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

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

最后，從機調用 API 產(chǎn)生 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，我們可以在后續(xù)的波形中看到。

握手波形

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

（1）VALID 信號等待 READY 信號

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

(2)READY 信號等待 VALID 信號

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

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

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

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

結語

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