這究竟屬于下一代驗證的方法、語言還是工具？

rockeric.com

首先聲明，便攜式激勵标準(PortableStimulus Standard, PSS)不是一種方法論，而是一種語言。使用語言我們可以有序地傳遞資訊，進而去建構工具，但工具也不是方法。我們所說的方法是指以某種可管理的方式系統地分解及解決問題的手段。工具可以支援方法，并且随着時間的推移，工具可以在方法标準化之後幫助管理方法。但目前還沒有針對PSS的标準方法，也沒有該語言定義的工具功能。

用便攜式激勵文法所說明的基于圖形的驗證技術，在供應商之間提供了某種程度的通用性，這種基于圖形的驗證技術即我們所用的工具，這些工具可以在現有的方法論中使用，也可以建立以前的工具不支援的新工具。當供應商提供标準之外的功能時，使用者群體會決定這些功能的有用程度，并将有用的部分打包到标準的未來版本中，忽略不太有用的部分。這其實就是語言的演變過程，特别是對于在标準出現之前就定義了的語言來說。

舉個例子，上一代驗證解決方案依賴于功能覆寫率來确定特定測試用例的價值，用RTL功能覆寫率度量的覆寫率代替驗證意義上的覆寫率。運作測試時，它認為設計中的值等同于正在執行的預期行為。驗證工程師很難建立良好的功能覆寫率模型，更難通過修改限制來增加覆寫率。

使用便攜式激勵工具會捕捉設計的預期行為，其目标是意圖覆寫，它确切地知道一個特定的測試用例應該覆寫什麼樣設計意圖。這樣看起來RTL上的功能覆寫率似乎不能提供其他額外的資訊。

并非如此。如果PSS模型遺漏了預期行為的一部分，那該怎麼辦？相對地，如果RTL沒能實作所有需要的功能，又該怎麼辦？基于圖形的意圖覆寫僅表示測試生成工具認為測試的完整程度，RTL上的功能覆寫不能找到丢失的功能，是以意圖覆寫和RTL功能覆寫之間的互相補充可以保證功能的完整性。

這種兩面性正是設計和驗證的核心。它需要兩個獨立的模型，系統地對進行比較，找出可能在設計、測試平台或規範中出現的缺陷的差異。但問題是：PSS使用者将發覺，與PSS中提供的功能覆寫率相比，RTL功能覆寫率的舊概念有多重要？功能覆寫率隻能在仿真中收集。單元級的模拟速度雖然很快，但卻無法測試系統級行為，系統級測試平台很慢，這就意味着不能運作大量的測試。

意圖覆寫是否應該與仿真中的功能覆寫相關聯，以獲得對PSS模型的信任，然後應用硬體仿真、FPGA和post-silicon來适當覆寫其餘的大型意圖覆寫空間？這由使用者決定的，繼續使用現有的功能覆寫機制的确為使用者從一個解決方案遷移到另一個解決方案提供了一種熟悉的機制。使用者可能會發現它非常有用，特别是在剛開始的時候。或者也可能認為其得不償失，這種機制不值得，當然了，功能覆寫現如今被看作是一項要耗費大量時間和精力的工作。

随着時間的推移，方法不斷進行優化，同時也在建立相應的工具，比如，幫助提供自動化和追蹤。現有的驗證管理器類似一個中央駕駛艙，在這裡可以存儲結果和進度，并啟動新的驗證活動。首次定義帶限制随機時還沒有驗證管理器，直到它實踐到最佳才開始出現。如果你認為這些管理器是基于PSS解決方案的正确使用方法，那就錯了。畢竟使用者還沒有機會确定如何使用現有的解決方案以及希望在其中看到的更改。

在Breker，我們鼓勵使用者群體探索優化他們時間和資源的方法，并提供我們認為對探索有所幫助的功能，并期望其中的一些功能能被廣泛應用。例如，TrekSoC可以提前生成完整的測試，也可以是被動生成的。它能夠生成在嵌入式處理器上運作的代碼，或者利用與DUT的事務通信，兩者兼有也可。每種方式支援不同的方法論。

我們一直并将繼續響應使用者的需求，可能是通過現有方法的擴充，例如圍繞System Verilog和UVM設計的方法，或者是新方法的建立，這些新方法到目前為止依賴于手動工作，沒有任何形式的自動化或追蹤技術。

作為供應商，我們會了解多數使用者正在做什麼嘗試，并對這些功能的改進支援力度。方法學就是這樣發展壯大的，我們一起努力就可以做到。

◆ ◆ ◆ ◆ ◆

作者介紹

Adnan Hamid, CEO of Breker

Adnan Hamid是Breker的創始人兼首席執行官，也是核心技術的發明者。在他的上司下，Breker已經成為複雜片上系統系統(SoC)功能驗證技術，特别是便攜式激勵技術的市場上司者。Breker在自驗證測試用例自動化方面的專業知識為SoC的驗證完整性設定了标準。

原文來自：https://www10.edacafe.com/blogs/thebrekertrekker/2019/01/15/methodology-language-and-tools/#more-2112

往期精彩：

2019驗證VIP春季班早鳥報名通道掃碼報名稿！

二胎未生，程式員已死