先來看一段對驗(yàn)證的介紹：

如果驗(yàn)證計(jì)劃做得足夠好，那為什么還總會出現(xiàn)質(zhì)量問題和項(xiàng)目延期？說白了，驗(yàn)證工作需要做到以終為始。一個(gè)好的驗(yàn)證計(jì)劃應(yīng)該具備詳細(xì)描述的可量化目標(biāo)，同時(shí)做到資源的優(yōu)化使用和對實(shí)際情況的預(yù)估。

這段話給人一種最近剛寫出來的錯(cuò)覺，但實(shí)際上卻引用自 2005 年 Cadence 刊登在 EETimes 上的一篇文章。正如 Alphonse Karr 在 Les Guêpes 期間所說，“萬變不離其宗”。

話雖如此，但驗(yàn)證領(lǐng)域的確發(fā)生了很多變化。2005 年時(shí)還沒有可移植激勵(lì)標(biāo)準(zhǔn)（PSS，portable stimulus standard），形式化驗(yàn)證也尚處于起步階段。如果想做硬件仿真，設(shè)計(jì)初啟就要花費(fèi)幾個(gè)月時(shí)間。要是想用 FPGA 原型設(shè)計(jì)，首先得買些 FPGA。那時(shí)候的 RTL 仿真和現(xiàn)在一樣，承擔(dān)著驗(yàn)證的主力工作。實(shí)際上，驗(yàn)證工程師的工作主要包括手動啟動仿真，隨之分析結(jié)果。但彼時(shí)已經(jīng)出現(xiàn)了更好的方法，即 Cadence 2005 年收購 Verisity 后發(fā)布的初版 vManager，雖然那時(shí)還僅支持單一用戶。

從 2005 年，或者更準(zhǔn)確的說，從 1985 年開始，一個(gè)確實(shí)發(fā)生的變化就是設(shè)計(jì)規(guī)模的持續(xù)增加。筆者寫這篇文章的清晨，NVIDIA CEO Jensen Huang 在自家廚房發(fā)布了容納 540 億個(gè)晶體管的最新款 AI 芯片。更大的芯片不僅意味著驗(yàn)證引擎需要不斷提升處理更大設(shè)計(jì)的能力，也意味著統(tǒng)籌整個(gè)驗(yàn)證流程的工具也必須水漲船高。Cadence vManager 驗(yàn)證管理平臺已經(jīng)從最初單用戶演進(jìn)到如今對跨國企業(yè)所有用戶的支持。

多引擎部署

可以用物流公司來做個(gè)比喻。一家物流公司需要貨車和飛機(jī)，運(yùn)輸工具的性能固然重要，但其部署和調(diào)運(yùn)方式同樣關(guān)鍵。飛機(jī)并不會一定比貨車好 ，兩者用途不同且優(yōu)勢互補(bǔ)。同樣的道理，形式化驗(yàn)證并不一定比仿真或者模擬更好，它們也是互為補(bǔ)充的關(guān)系。vManager 平臺決定了這些引擎的部署方式，是驗(yàn)證流程的核心。在某種意義上講，其對引擎的驅(qū)動方式和引擎本身同樣重要，是第四引擎。

驗(yàn)證引擎相信大家都很熟悉，我就不再贅言。

vManager

如之前所說，vManager 平臺最初是為單一地點(diǎn)，單一團(tuán)隊(duì)提供支持而開發(fā)?，F(xiàn)在的公司運(yùn)行方式已和當(dāng)初大不相同。多個(gè)處于不同設(shè)計(jì)階段的項(xiàng)目同時(shí)運(yùn)行，設(shè)計(jì)團(tuán)隊(duì)分布在全球各地，很多驗(yàn)證都在大型服務(wù)器陣列或云端完成。從單一用戶至今的 15 年中，vManager 平臺經(jīng)歷了多次變革，本篇不做詳述，直接來了解一下當(dāng)前的 vManager。

今天，vManager 平臺的高可用性版本已經(jīng)被企業(yè)用于多項(xiàng)目并行管理，如上圖所示。

同時(shí) vManager 支持不同地區(qū)工作團(tuán)隊(duì)常見的服務(wù)器或網(wǎng)絡(luò)故障等分布式問題的處理，確保關(guān)鍵數(shù)據(jù)的同步性，并保持足夠的本地化來維持高性能，且進(jìn)一步擴(kuò)展至云端任務(wù)管理。vManager 的這些特性讓其真正成為了企業(yè)級解決方案。

與啟動 Xcelium 仿真相比，任務(wù)執(zhí)行需要做的事情更多：

回歸準(zhǔn)備

請求服務(wù)器場資源

啟動主機(jī)

數(shù)據(jù)加載

執(zhí)行任務(wù)

數(shù)據(jù)存儲

生成報(bào)告

故障分類

設(shè)計(jì) / 修復(fù)測試

vManager 平臺將上述工作全部自動化。列出的內(nèi)容背后還有很多細(xì)節(jié)，比如在請求服務(wù)器陣列資源中，任務(wù)排隊(duì)等候可用資源通常會占用超過 1 / 3 的驗(yàn)證時(shí)間。更糟的是，運(yùn)行時(shí)間最長的任務(wù)也有最久的延遲（因?yàn)樗鼈冃枰谜加酶噘Y源，屬于供應(yīng)短缺對象）。成本和運(yùn)行時(shí)間也與服務(wù)器不同配置相關(guān)，導(dǎo)致驗(yàn)證任務(wù)在復(fù)雜驗(yàn)證環(huán)境下的分配優(yōu)化也比以往更加繁瑣。

驗(yàn)證效率

vManager 平臺是驗(yàn)證計(jì)劃的核心。原因就如本文開頭的引言：“一個(gè)好的開發(fā)計(jì)劃應(yīng)該具備詳細(xì)描述的可量化目標(biāo)?！被氐?2005 年，vManager 平臺還只是一個(gè)單用戶工具，但也已經(jīng)比其他產(chǎn)品要領(lǐng)先很多，因?yàn)槟切┍砀窈湍_本可能都稱不上是一款產(chǎn)品。今天，隨著企業(yè)級版本的應(yīng)用，驗(yàn)證計(jì)劃可以跨區(qū)域，跨計(jì)算和技術(shù)平臺運(yùn)行，且擁有高可用性。

vManager 平臺的第二個(gè)企業(yè)級特性是將驗(yàn)證與 DOORS（來自IBM），REQTIFY（來自 Dassault）或 Jama 等需求管理系統(tǒng)連接，這對汽車、航空航天和國防領(lǐng)域非常重要。而對大型項(xiàng)目來說，這項(xiàng)特性可以更好地實(shí)現(xiàn)全系統(tǒng)的需求捕捉和追溯。vManager 平臺通過這些連接，將特定功能的驗(yàn)證與需求綁定并反饋。

總結(jié)

隨著 SoC 設(shè)計(jì)更加復(fù)雜，功能更多，SoC 的驗(yàn)證越發(fā)具有挑戰(zhàn)性。雪上加霜的是，如今產(chǎn)品上市時(shí)間從以前的數(shù)年計(jì)縮短到數(shù)月計(jì)，對測試工作造成了更大的壓力。為了解決大規(guī)模 SoC 驗(yàn)證的挑戰(zhàn)，一個(gè)功能全面、集中化、可擴(kuò)展且足夠靈活的解決方案不可或缺。這個(gè)解決方案就是vManager 平臺。

這也是許多頭部半導(dǎo)體企業(yè)選擇 vManager 平臺作為其驗(yàn)證規(guī)劃解決方案的主要原因。

原文標(biāo)題：vManager：驗(yàn)證之核心

文章出處：【微信公眾號：Cadence楷登】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。