基于OVM的網絡協議處理芯片驗證平臺的設計

摘 要： 針對一款網絡協議處理芯片，為了保證其設計的正確性，提升驗證效率，基于OVM架構，通過SystemVerilog語言搭建了具有受約束的隨機激勵生成、錯誤注入、覆蓋率收集、正確性自檢查等功能的驗證平臺。通過該驗證平臺對芯片進行了全方位的高效驗證，實現了一次流片成功。基于OVM的驗證平臺具有良好的可重用性和可擴展性，相對于傳統的編寫定向測試激勵的方法，在驗證的高效性、完備性上具有顯著的優勢。

關鍵詞： OVM； SystemVerilog語言； 網絡協議處理芯片； 隨機激勵； 驗證平臺

中圖分類號： TN47?34； TN492 文獻標識碼： A 文章編號： 1004?373X（2014）01?0137?04

0 引 言

隨著集成電路設計技術發展和設計規模的不斷膨脹，對設計正確性的驗證所耗費的時間越來越長。驗證工作大約占據整個項目周期70%左右的時間[1]。驗證工作全面與否和效率的高低直接關系到集成電路產品設計的成敗和上市的時間。

傳統的通過Verilog語言撰寫定向測試激勵的方式只能適應規模較小的設計，對于超大規模的集成電路的正確性驗證則難以勝任。SystemVerilog語言是近幾年發展起來的、并在大規模集成電路的驗證工作上迅速得到廣泛應用的、一門集設計與驗證為一體的硬件驗證語言，它引入面向對象編程的思想，并且支持覆蓋率收集、受約束的隨機化等對驗證來講非常重要的特性。基于SystemVerilog語言，可以構建由覆蓋率驅動的并且受約束的隨機激勵驗證平臺[2?3]。

隨機激勵對于測試復雜設計十分關鍵。定向測試可以找出設計中預期的漏洞，而隨機測試則能夠找出預料不到的漏洞。搭建隨機激勵驗證平臺花費的時間很長，但其回報卻很高。每個隨機測試都可以共享這個通用的驗證平臺，而不像每個定向測試都要從零開始編寫。受約束的隨機激勵驗證平臺找起漏洞來會比定向測試快很多。

OVM是Cadence和Mentor兩家公司聯合推出的仿真驗證方法學，它是業界第一個開源的仿真驗證資源庫，它為驗證工程師提供了開源的基類設計代碼，可以用于構建可復用的驗證環境，并且支持事務級傳輸模型的接口通信[4]。

本文基于OVM架構，通過SystemVerilog語言，給出了一款網絡協議處理芯片驗證平臺的設計。

1 OVM簡介

OVM驗證平臺由可重用的稱之為OVM驗證組件（OVCs）的驗證環境構成。OVC可以是針對接口協議、子模塊或者完整的系統而構建的驗證環境。每個OVC遵循相同的結構，可以對具體的協議或設計執行仿真、檢查和覆蓋率收集。OVC被用于驗證待測設計（DUT）的正確性。OVC可以加速DUT驗證平臺的創建[5]。

典型的OVC環境如圖1所示。

圖1 OVC環境示意圖

一個完整的OVC環境由Data Item、Driver、Sequencer、Monitor、Agent、Environment組成，詳細描述見參考文獻[5]。

2 驗證平臺的設計實現

2.1 驗證對象的描述

圖2所示為網絡協議處理芯片的簡易結構。芯片對外提供四組接口：兩組網絡接口、一組配置管理接口、一組SRAM接口。兩組網絡接口相互通信，從一個網口輸入的網絡數據包經協議處理單元處理后從另一個網口輸出；配置管理口與外部CPU通信，實現芯片的初始化配置、狀態監控； SRAM接口與外部存儲器連接，提供網絡數據處理過程中所需的中間數據緩存的通道。

圖2 網絡協議處理芯片結構

2.2 驗證平臺的結構

針對該網絡協議處理芯片構建的驗證平臺結構如圖3所示。芯片的SRAM接口與標準的SRAM模型對接，實現讀寫時序的控制和數據的交互；其他的三組接口分別構建獨立的可重用的OVM驗證組件（OVC）；Virtual Sequencer容納各個OVC的sequencer，控制各個OVC隨機序列的生成和管理；Scoreboard收集各OVC提供的監測數據，通過與參考模型（RM）的輸出結果進行比較，確認芯片輸出的正確性；根據芯片的測試驗證需求，組合相關的測試序列，生成多組test，供芯片測試驗證。

2.3 驗證平臺的設計

2.3.1 OVC設計

芯片驗證平臺包含GMAC OVC1、GMAC OVC2和CFG OVC三個獨立的驗證組件。本文以GMAC OVC1為例，詳述OVC的構建方法。

（1） Data Item

GMAC OVC1為網絡接口的驗證組件，驅動網絡接口的數據為以太網數據包。以太網數據包可以采用分層的方法逐級構建。首先構建鏈路層的MAC數據包，對MAC頭各字段進行隨機化定義和約束；然后構建網絡層的IP數據包，對IP頭的各字段進行隨機化定義和約束，IP數據包繼承于鏈路層的MAC數據包；最后構建傳輸層的ICMP、UDP、TCP等協議包，這些數據包繼承于網絡層的IP包。通過這種面向對象的分層構建方法，使該Data Item具有良好的擴展性，在不同的應用中，根據實際需求可方便地對網絡層和傳輸層的數據包進行擴展。

圖3 驗證平臺結構

在逐層構建數據包時，除產生正確的數據包外，為了檢驗芯片的容錯能力，還需注入一定比例的錯誤數據包，如同步頭錯誤、CRC校驗和錯誤、IP頭校驗和錯誤等。

（2） Sequencer

Sequencer中寄存著不同種類的sequence，這些sequence產生不同類型的數據包，在task body（）中生成。示例代碼如下：

virtual task body（）；

case（ip_sel） //包類型選擇

TCP： begin

[′ovm_do_with]（tcp_packet0，{tcp_packet0.packet_type==IP_PACKET； tcp_packet0.ip_type==TCP； }） end //生成TCP包

UDP： begin

[′ovm_do_with]（udp_packet0，{udp_packet0.packet_type==IP_PACKET； udp_packet0.ip_type==UDP； }） end //生成UDP包

ICMP： begin

[′ovm_do_with]（icmp_packet0，{icmp_packet0.packet_type==IP_PACKET； icmp_packet0.ip_type==ICMP； }） end

//生成ICMP包

endcase

endtask： body

（3） Driver

Driver從Sequencer中獲取Data Item，然后將其轉換成DUT網絡接口支持的邏輯方式和時序方式驅動到接口。

Driver與Sequencer之間的通信通過OVM提供的TLM端口實現。

seq_item_port.get_next_item（req）；

//TLM端口，從sequencer中取出新的數據序列

drive_frame（req）； //自定義任務，驅動數據序列到DUT端口

seq_item_port.item_done（）；

//TLM端口，通知sequencer取出的數據序列處理完

（4） Monitor

Monitor監測GMAC1的接口，收集輸入、輸出數據序列，并進行功能覆蓋率統計。

功能覆蓋率通過covergroup中的coverpoint和cross來實現，示例如下：

covergroup cover_ip_packet；

ip_total_len： coverpoint ip_collected.ip_total_len

//創建覆蓋點ip_total_len

{ bins small_packet[]={[21：46]}；

bins normal_packet[]={[47：1500]}； }

ip_protocal： coverpoint ip_collected.ip_protocal

//創建覆蓋點ip_protocal

{ bins icmp = {1}；

bins tcp = {6}；

bins udp = {17}； }

cross ip_total_len，ip_protocal；