來源：內(nèi)容由 公眾號(hào) 路科驗(yàn)證 （ID：Rocker-IC）編輯部 原創(chuàng)，謝謝！

首先聲明，便攜式激勵(lì)標(biāo)準(zhǔn)(PortableStimulus Standard, PSS)不是一種方法論，而是一種語言。使用語言我們可以有序地傳遞信息，從而去構(gòu)建工具，但工具也不是方法。我們所說的方法是指以某種可管理的方式系統(tǒng)地分解及解決問題的手段。工具可以支持方法，并且隨著時(shí)間的推移，工具可以在方法標(biāo)準(zhǔn)化之后幫助管理方法。但目前還沒有針對(duì)PSS的標(biāo)準(zhǔn)方法，也沒有該語言定義的工具功能。

用便攜式激勵(lì)語法所說明的基于圖形的驗(yàn)證技術(shù)，在供應(yīng)商之間提供了某種程度的通用性，這種基于圖形的驗(yàn)證技術(shù)即我們所用的工具，這些工具可以在現(xiàn)有的方法論中使用，也可以創(chuàng)建以前的工具不支持的新工具。當(dāng)供應(yīng)商提供標(biāo)準(zhǔn)之外的功能時(shí)，用戶群體會(huì)決定這些功能的有用程度，并將有用的部分打包到標(biāo)準(zhǔn)的未來版本中，忽略不太有用的部分。這其實(shí)就是語言的演變過程，特別是對(duì)于在標(biāo)準(zhǔn)出現(xiàn)之前就定義了的語言來說。

舉個(gè)例子，上一代驗(yàn)證解決方案依賴于功能覆蓋率來確定特定測試用例的價(jià)值，用RTL功能覆蓋率度量的覆蓋率代替驗(yàn)證意義上的覆蓋率。運(yùn)行測試時(shí)，它認(rèn)為設(shè)計(jì)中的值等同于正在執(zhí)行的預(yù)期行為。驗(yàn)證工程師很難創(chuàng)建良好的功能覆蓋率模型，更難通過修改約束來增加覆蓋率。

使用便攜式激勵(lì)工具會(huì)捕捉設(shè)計(jì)的預(yù)期行為，其目標(biāo)是意圖覆蓋，它確切地知道一個(gè)特定的測試用例應(yīng)該覆蓋什么樣設(shè)計(jì)意圖。這樣看起來RTL上的功能覆蓋率似乎不能提供其他額外的信息。

并非如此。如果PSS模型遺漏了預(yù)期行為的一部分，那該怎么辦？相對(duì)地，如果RTL沒能實(shí)現(xiàn)所有需要的功能，又該怎么辦？基于圖形的意圖覆蓋僅表示測試生成工具認(rèn)為測試的完整程度，RTL上的功能覆蓋不能找到丟失的功能，所以意圖覆蓋和RTL功能覆蓋之間的相互補(bǔ)充可以保證功能的完整性。

這種兩面性正是設(shè)計(jì)和驗(yàn)證的核心。它需要兩個(gè)獨(dú)立的模型，系統(tǒng)地對(duì)進(jìn)行比較，找出可能在設(shè)計(jì)、測試平臺(tái)或規(guī)范中出現(xiàn)的缺陷的差異。但問題是：PSS用戶將發(fā)覺，與PSS中提供的功能覆蓋率相比，RTL功能覆蓋率的舊概念有多重要？功能覆蓋率只能在仿真中收集。單元級(jí)的模擬速度雖然很快，但卻無法測試系統(tǒng)級(jí)行為，系統(tǒng)級(jí)測試平臺(tái)很慢，這就意味著不能運(yùn)行大量的測試。

意圖覆蓋是否應(yīng)該與仿真中的功能覆蓋相關(guān)聯(lián)，以獲得對(duì)PSS模型的信任，然后應(yīng)用硬件仿真、FPGA和post-silicon來適當(dāng)覆蓋其余的大型意圖覆蓋空間？這由用戶決定的，繼續(xù)使用現(xiàn)有的功能覆蓋機(jī)制的確為用戶從一個(gè)解決方案遷移到另一個(gè)解決方案提供了一種熟悉的機(jī)制。用戶可能會(huì)發(fā)現(xiàn)它非常有用，特別是在剛開始的時(shí)候。或者也可能認(rèn)為其得不償失，這種機(jī)制不值得，當(dāng)然了，功能覆蓋現(xiàn)如今被看作是一項(xiàng)要耗費(fèi)大量時(shí)間和精力的工作。

隨著時(shí)間的推移，方法不斷進(jìn)行優(yōu)化，同時(shí)也在創(chuàng)建相應(yīng)的工具，比如，幫助提供自動(dòng)化和追蹤。現(xiàn)有的驗(yàn)證管理器類似一個(gè)中央駕駛艙，在這里可以存儲(chǔ)結(jié)果和進(jìn)度，并啟動(dòng)新的驗(yàn)證活動(dòng)。首次定義帶約束隨機(jī)時(shí)還沒有驗(yàn)證管理器，直到它實(shí)踐到最佳才開始出現(xiàn)。如果你認(rèn)為這些管理器是基于PSS解決方案的正確使用方法，那就錯(cuò)了。畢竟用戶還沒有機(jī)會(huì)確定如何使用現(xiàn)有的解決方案以及希望在其中看到的更改。

在Breker，我們鼓勵(lì)用戶群體探索優(yōu)化他們時(shí)間和資源的方法，并提供我們認(rèn)為對(duì)探索有所幫助的功能，并期望其中的一些功能能被廣泛應(yīng)用。例如，TrekSoC可以提前生成完整的測試，也可以是被動(dòng)生成的。它能夠生成在嵌入式處理器上運(yùn)行的代碼，或者利用與DUT的事務(wù)通信，兩者兼有也可。每種方式支持不同的方法論。

我們一直并將繼續(xù)響應(yīng)用戶的需求，可能是通過現(xiàn)有方法的擴(kuò)展，例如圍繞System Verilog和UVM設(shè)計(jì)的方法，或者是新方法的創(chuàng)建，這些新方法到目前為止依賴于手動(dòng)工作，沒有任何形式的自動(dòng)化或追蹤技術(shù)。

作為供應(yīng)商，我們會(huì)了解多數(shù)用戶正在做什么嘗試，并對(duì)這些功能的改進(jìn)支持力度。方法學(xué)就是這樣發(fā)展壯大的，我們一起努力就可以做到。

---

作者介紹

Adnan Hamid, CEO of Breker

Adnan Hamid是Breker的創(chuàng)始人兼首席執(zhí)行官，也是核心技術(shù)的發(fā)明者。在他的領(lǐng)導(dǎo)下，Breker已經(jīng)成為復(fù)雜片上系統(tǒng)系統(tǒng)(SoC)功能驗(yàn)證技術(shù)，特別是便攜式激勵(lì)技術(shù)的市場領(lǐng)導(dǎo)者。Breker在自驗(yàn)證測試用例自動(dòng)化方面的專業(yè)知識(shí)為SoC的驗(yàn)證完整性設(shè)定了標(biāo)準(zhǔn)。

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

總結(jié)

以上是生活随笔為你收集整理的uvm 形式验证_这究竟属于下一代验证的方法、语言还是工具？||路科验证的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。