背景
基于SystemVerilog的驗證引入了接口的概念來表示設計模塊之間的通信。在其最基本的形式中,SystemVerilog 接口只是一個命名的信號束,可以通過模塊端口作為單個項目進行通信。然后,接收此接口的設計模塊可以通過此接口參考訪問信號。但是,接口的更高級別函數也可以提供更強類型的通信,以更好地表示設計意圖。以下是系統Verilog接口中可用的高階函數的子集:
可以通過使用時鐘塊和模塊端口在信號列表上執行訪問規則
函數和任務可用于封裝高階排序或訪問控制
初始塊和始終塊等進程可以添加功能
連續賦值語句還可以添加功能
斷言可以確保正確的集成
SystemVerilog 接口的一個非常重要的用途是將靜態設計元素連接到動態測試平臺元素。動態測試平臺元素需要訪問靜態設計元素才能采樣和驅動信號,但可重用的測試平臺元素無法訪問靜態設計元素,除非通過稱為虛擬接口的特殊構造。虛擬接口是測試平臺代碼中的接口句柄,可以與接口實例一起分配。虛擬接口是動態屬性,可以分配給不同測試平臺中的不同接口實例,從而提高可重用性。
設計可重用設計塊的常用技術是使用參數使設計塊的不同實例具有獨特的特征。例如,可以對模塊進行參數化,以允許在聲明模塊并提供參數值時定義數據總線寬度。SystemVerilog 接口也支持參數化,但參數化接口的使用在測試平臺端帶來了不可預見的復雜性。為了與賦值兼容,參數化虛擬接口必須專用于接口實例專用的相同值。除非采取預防措施,否則這可能會使一些非常丑陋的測試平臺代碼具有更丑陋的使用模型。
參數擴散:蠻力法
參數化虛擬接口引入的問題是,訪問它的測試平臺元素必須知道強類型接口。因此,當接口專用化尚未知時,無法編寫泛型類以使用參數化虛擬接口。此問題的一個解決方案是參數化訪問參數化虛擬接口的類。例如,可以使用 UVM 驅動程序必須使用的虛擬接口類型進行參數化。然而,這只是將問題向上移動了一層,因為現在實例化該參數化驅動程序的代理也必須參數化,以便它可以創建驅動程序的正確專用實例。這會不斷向上移動,直到您到達“知道”正在測試的特定專業化存在的頂層測試平臺組件。以下代碼段演示了此問題。
首先,我們定義參數化的虛擬接口:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
接下來,我們定義可重復使用的 VIP 代碼。此測試平臺代碼必須設計為可在參數化接口可以使用的任何環境中重用,因此還必須參數化VIP代碼本身,以便可以訪問正確的接口。以下代碼段演示必須如何參數化 UVM 驅動程序類和包含該驅動程序的代理:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
//======================================================================= class param_driver#(type vif_t=param_vif) extends uvm_driver#(cust_data);
`uvm_component_param_utils(param_driver#(vif_t))
vif_t vif;
function void build_phase(uvm_phase phase);
if (!uvm_config_db#(vif_t)::get(this, "", "vif", vif))
`uvm_fatal("build", "A valid interface was not received.");
endfunction endclass //======================================================================= class cust_agent#(type vif_t=param_vif) extends uvm_agent;
`uvm_component_param_utils(param_agent#(vif_t))
vif_t vif;
param_driver#(vif_t) param_driver;
function void build_phase(uvm_phase phase);
if (!uvm_config_db#(vif_t)::get(this, "", "vif", vif))
`uvm_fatal("build", "A valid interface was not received.");
uvm_config_db#(vif_t)::set(this, "param_driver", "vif", vif);
param_driver = param_driver#(vif_t)::type_id::create("param_driver", this);
endfunction endclass |
到目前為止,這看起來還不錯!它給類定義增加了一點復雜性,但不會太多。然而,在你檢查測試平臺必須如何訪問這些參數化類之前,這些問題不會變得明顯。以下段顯示了測試如何根據接口的參數化方式唯一地訪問 VIP 的每個實例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
//======================================================================= class cust_test extends uvm_test;
`uvm_component_utils(cust_test)
param_agent#(virtual param_if#(8)) param_agent8;
param_agent#(virtual param_if#(16)) param_agent16;
param_agent#(virtual param_if#(32)) param_agent32;
virtual function void build_phase(uvm_phase phase);
param_agent8 = param_agent#(virtual param_if#(8))::type_id::create("param_agent8", this);
param_agent16 = param_agent#(virtual param_if#(16))::type_id::create("param_agent16", this);
param_agent32 = param_agent#(virtual param_if#(32))::type_id::create("param_agent32", this);
endfunction endclass //======================================================================= module test_top;
param_if#(8) if8();
param_if#(16) if16();
param_if#(32) if32();
initial begin
uvm_config_db#(virtual param_if#(8))::set(uvm_root::get(), "uvm_test_top.param_agent8", "vif", if8);
uvm_config_db#(virtual param_if#(16))::set(uvm_root::get(), "uvm_test_top.param_agent16", "vif", if16);
uvm_config_db#(virtual param_if#(32))::set(uvm_root::get(), "uvm_test_top.param_agent32", "vif", if32);
run_test("cust_test");
end endmodule |
如您所見,對 VIP 的每個引用都必須使用要使用的正確接口類型進行參數化。這不僅會影響VIP建設,還會影響回調注冊、工廠覆蓋等。這給測試平臺開發人員帶來了很大的負擔,并限制了這些環境的可重用性。
向驗證組件添加參數是可重用VIP的有效技術解決方案,但它使使用模型大大復雜化,并限制了測試平臺的可重用性。
審核編輯:郭婷
-
接口
+關注
關注
33文章
8685瀏覽量
151655 -
Verilog
+關注
關注
28文章
1351瀏覽量
110243 -
UVM
+關注
關注
0文章
182瀏覽量
19205
發布評論請先 登錄
相關推薦
評論