1. 有效的驗(yàn)證需要驗(yàn)證工程師使用不同于設(shè)計(jì)者的思維方式思考問(wèn)題。具體來(lái)說(shuō)，驗(yàn)證更加關(guān)心在嚴(yán)格遵循協(xié)議的基礎(chǔ)上發(fā)現(xiàn)設(shè)計(jì)里面的bug，搜索corner cases，對(duì)設(shè)計(jì)的不一致要保持零容忍的態(tài)度。
mindset：一套人們應(yīng)該持有的確定的態(tài)度，有時(shí)候又被描述為心里慣性，群體思維，范式，在分析和決策過(guò)程中很難抵消mindset的影響。
舉一個(gè)簡(jiǎn)單的例子，當(dāng)你看到任何verification engineer的職位，你會(huì)發(fā)現(xiàn)這是一個(gè)關(guān)于語(yǔ)言，方法學(xué)，工具以及某種領(lǐng)域的知識(shí)集合。
?很多有經(jīng)驗(yàn)的工程師可以學(xué)習(xí)閱讀一個(gè)規(guī)范，建立驗(yàn)證規(guī)范，以及編寫(xiě)充分的代碼去實(shí)現(xiàn)，但是卻在某個(gè)關(guān)鍵的點(diǎn)達(dá)不到驗(yàn)證的目的。
本文將試圖使用能夠出現(xiàn)在驗(yàn)證環(huán)境中的一系列關(guān)鍵的選擇揭示驗(yàn)證心態(tài)：? ?1.?Is it the verification?environment’s duty?to accurately?replicate the real?world？驗(yàn)證環(huán)境是否有責(zé)任復(fù)制真實(shí)的環(huán)境？2.Is it acceptable for the testbench and/or testcases to make use of design signals?是否允許TB或者testcase使用設(shè)計(jì)的信號(hào)3.?Is it worthwhile to target corner cases that designers consider invalid?考慮設(shè)計(jì)者認(rèn)為無(wú)效的corner cases是否值得
合格的驗(yàn)證mindset跟設(shè)計(jì)mindset有很大的不同，需要多年的經(jīng)驗(yàn)，指點(diǎn)，以及在困難中摸索的經(jīng)歷才能培養(yǎng)出來(lái)。這貫穿在：每一個(gè)決定，每一行代碼，每一次會(huì)議，每一個(gè)項(xiàng)目。對(duì)設(shè)計(jì)為中心的驗(yàn)證方法說(shuō)不！！！
當(dāng)前，驗(yàn)證思維，依舊是一個(gè)被低估和弱勢(shì)的產(chǎn)業(yè)。在本文中,我們將分析為什么這個(gè)驗(yàn)證有效性的話題如此關(guān)鍵。我們也將討論影響一個(gè)TB debuggability的決策。在這個(gè)文章里面，我們將介紹一個(gè)驗(yàn)證工程師應(yīng)該做的，而不是他們應(yīng)該如何做。
1.?INTEROPERATING VERSUS STRESSING（互操作對(duì)抗強(qiáng)調(diào)）?驗(yàn)證里面最重要的挑戰(zhàn)就是劃出設(shè)計(jì)強(qiáng)調(diào)的重點(diǎn)，并與設(shè)計(jì)進(jìn)行互操作。只有懷有正確的mindset，才可以正確的劃分驗(yàn)證重點(diǎn)，這些里面比較常見(jiàn)的有：1.?clock and data recovery (CDR) 時(shí)鐘和數(shù)據(jù)恢復(fù)2. 錯(cuò)誤情況下的握手3. 狀態(tài)指標(biāo)，例如fifo的空滿
A. 時(shí)鐘數(shù)據(jù)恢復(fù)1. 一些協(xié)議規(guī)定，數(shù)據(jù)在發(fā)送和接收的時(shí)候沒(méi)有附帶的時(shí)鐘信號(hào)。在這種情況下，設(shè)計(jì)需要實(shí)現(xiàn)這個(gè)協(xié)議需要實(shí)現(xiàn)一個(gè)時(shí)鐘數(shù)據(jù)恢復(fù)功能，以便在傳輸過(guò)來(lái)的數(shù)據(jù)里面提取時(shí)鐘。針對(duì)這個(gè)設(shè)計(jì)，開(kāi)發(fā)VC驗(yàn)證組件，也有一個(gè)相似的需求，沒(méi)有時(shí)鐘信號(hào)發(fā)送和接收，只有數(shù)據(jù)。

如圖所示，當(dāng)實(shí)現(xiàn)VC的監(jiān)控,驗(yàn)證工程師必須決定以哪種方法收到來(lái)自DUT的數(shù)據(jù)。是否應(yīng)該在monitor實(shí)現(xiàn)一個(gè)CDR算法，而這個(gè)算法已經(jīng)在設(shè)計(jì)中實(shí)現(xiàn)過(guò)。當(dāng)然不是這樣，更好的解決辦法是實(shí)現(xiàn)一個(gè)路差分(鎖相環(huán))算法基于相同的參考時(shí)鐘DUT使用作為參考,并利用鎖相環(huán)的輸出樣本輸入數(shù)據(jù)。
This approach accomplishes the following: 1. ?It verifies that the DUT’s data stream is in sync with the?reference clock2. ?It avoids any possibility of the testbench masking a?problem because the CDR algorithm is too tolerant3. ?It has better simulation performance than doing costly?checks on data rates4. ?It is faster and simpler to implement than CDR我們來(lái)看看驗(yàn)證視角和設(shè)計(jì)視角有什么不同：當(dāng)構(gòu)建一個(gè)RTL CDR組件,設(shè)計(jì)師努力用最健壯的方式構(gòu)建算法,能夠與廣泛的外部設(shè)備交互。而驗(yàn)證工程師反而試圖盡量創(chuàng)建不夠強(qiáng)健的算法。so it stresses the design and fails on the slightest?deviation from the protocol specification.因此，驗(yàn)證的目標(biāo)不是為了復(fù)制現(xiàn)實(shí)，而是盡可能全面的驗(yàn)證設(shè)計(jì)，雖然可能這有可能不是很現(xiàn)實(shí)。
B.? Handshaking Error Handling?大部分的協(xié)議要求使用一組反饋信息 ACK/NACK報(bào)文來(lái)指示在最近接受的傳輸中是否有錯(cuò)誤產(chǎn)生。

1. 如果按照設(shè)計(jì)的思維，VC的實(shí)現(xiàn)應(yīng)該遵循協(xié)議規(guī)范，也就是說(shuō)自動(dòng)發(fā)送ACK，當(dāng)接受到一筆沒(méi)有錯(cuò)誤的傳輸，自動(dòng)發(fā)送NACK當(dāng)接收到一筆錯(cuò)誤的傳輸。2. 上面的似乎忽視一種情況，正常情況下DUT永遠(yuǎn)不會(huì)產(chǎn)生錯(cuò)誤的傳輸。那么TB也就會(huì)永遠(yuǎn)不會(huì)返回NACK。3. 而驗(yàn)證組件需要負(fù)責(zé)產(chǎn)生這么一個(gè)錯(cuò)誤，the testcase writer must be?able to manually control the VC to send a NACK in response.4. 還有另外一種情況，就是握手異常的情況，就是握手信號(hào)沒(méi)有返回給design。這要求VC需要support 錯(cuò)誤插入的功能。5. 驗(yàn)證VC如果實(shí)現(xiàn)完整的協(xié)議會(huì)導(dǎo)致驗(yàn)證失敗以及浪費(fèi)精力。
C.? Status Indicators and Clocks （這是大家都知道的典型，這里省略）

OUTSIDE-THE-BOX VERIFICATION PLANNING?
A. Corner case identification：1.?Function Input Parametersa. whether or not something is valid or?invalid is in fact irrelevant; what is important is, can such a?scenario ever happen, and if the answer it “yes”, then it must be?simulated to ensure that the design recovers from it. ?b. It was the responsibility of the?verification engineer to take a higher-level view of things in?order to build the best possible verification environment.?2. Register Accesses:考慮這種情況：a design is specified to have a?low-power mode that can be activated by writing a ‘1’ to a?given register bit.? The bit’s default value is ‘0’, making the?device be in normal mode by default.? In th1. 首先我們應(yīng)該很容易想到測(cè)試如下的情況：?x? Write ‘1’ to the low-power bitx? Check that the device enters low-power mode x? Write ‘0’ to the low-power bit x? Check that the device exits low-power mode2. 但是有另外一種情況沒(méi)有考慮到：what?happens when a ‘0’ is written to the bit when the bit is already?‘0’ (or a ‘1’ when it is already ‘1’)??這里面會(huì)隱含一個(gè)關(guān)鍵性的錯(cuò)誤，說(shuō)不定在0的情況下寫(xiě)0回不正確的進(jìn)入低功耗模式。
驗(yàn)證計(jì)劃包括所有可能發(fā)生的事情,不管是否DUT旨在處理它們,和無(wú)論設(shè)計(jì)師可能會(huì)說(shuō)什么。
As you?can imagine, doing error injection in creative ways greatly?expands the search space for finding bugs, and so experience?and a degree of gut-feeling is required to target those areas?most likely to be concealing real bugs. ?Where is the line?between inter-operating with?the design and?stressing it?
PRIORITIZING DEBUGGABILITY?
1. 一個(gè)良好的TB強(qiáng)調(diào)可調(diào)試性！！A.? Protocols with Bi-Directional Ports?
Some devices try to save on pins and board trace routing by?employing bi-directional ports for data and/or clock signals. ?這種協(xié)議的本質(zhì)，至少有兩個(gè)設(shè)備負(fù)責(zé)驅(qū)動(dòng)數(shù)據(jù)和時(shí)鐘信號(hào)，否則也不會(huì)使用雙向端口。
上面是一種接口的實(shí)現(xiàn)方式，這種方式的可調(diào)試很低，因?yàn)樗械腄UT和VC連接在同一個(gè)雙向端口，但是很難確定到底是哪個(gè)組件在驅(qū)動(dòng)總線。
Using a verification mindset, we make use of both?unidirectional and bi-directional signals to achieve both ease of?debug and adherence to the protocol. ?
(In Figure 10, “(highz1, strong0)” means “when signal is?assigned with a ‘1’, it takes on ‘Z’; when it is assigned to with?a ‘0’, it takes on ‘0’ ”).?
在DUT里面，使用如下方式驅(qū)動(dòng)：

ROUNDING OUT THE MINDSET?
To what extent must?the verification?component follow?the design?protocol?驗(yàn)證組件在多大程度上必須遵循設(shè)計(jì)協(xié)議？
The DUT is sending data without an?accompanying clock - should my VC do?Clock-Data-Recovery?...NoDUT發(fā)送數(shù)據(jù)沒(méi)有附帶時(shí)鐘- 我的VC是否需要做Clock-Data-Recovery

The protocol has bi-directional signals?with the potential for multiple masters. ?Should I split each signal into two at the?VC interface level?... Yes.
?


?V. ?ROUNDING OUT THE MINDSET?

A. No coverage without Checking:沒(méi)有檢查就沒(méi)有覆蓋率? 以前面對(duì)一個(gè)low-power使能位寫(xiě)0當(dāng)這個(gè)bit為0的時(shí)候?yàn)槔?#xff0c;突出了另一個(gè)驗(yàn)證心態(tài)，就是never do coverage on?anything in the absence of doing checks.? This rules out doing?register value coverage, because it is misleading at best and a?waste of compute resources in a large system-on-a-chip (SOC).?
B?Approach to Debugging 調(diào)試的方法：1. 使用waveform的方式debug并不適合VC，因?yàn)楹芏嗖僮鞑⒉幌娜魏螘r(shí)間，在發(fā)送激勵(lì)的時(shí)候使用動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)。應(yīng)該有一種心態(tài)，最好的debug 工具應(yīng)該是logfile本身。對(duì)于logfile：1. 要有適當(dāng)?shù)暮鸵恢碌南⒛Ｊ?. 當(dāng)然這并不是說(shuō)，可以不用波形去調(diào)試，但是更應(yīng)該依靠日志。3. 如果不能夠使用logfile去debug，那只能說(shuō)明消息機(jī)制需要提高。
C.? Zoom-In, Zoom-Out Thinking?
When zoomed-in the engineer does tasks such as: x? Understand design specifications x? Write verification plans based on the specification x? Write code to implement the verification plan x? Write testcase code x? Debug failing testcases?
Verification engineers must also do a series of tasks while?zoomed-out such as:x? Decide which design features to focus on to maximize?bug discovery?Devise creative ways to tease bugs outx? Allocate time so as to get? the most important checking?and coverage for the effort ?
The main reason for this is difference is that verifiers need?to deal with a larger scope than designers do. ?? ?1. 不同于設(shè)計(jì)必須在tapeout之前完成他們的工作，驗(yàn)證可以再tapeout之后繼續(xù)進(jìn)行，或者放棄? ?2. 驗(yàn)證人員想做到這一點(diǎn)，必須要接觸廣泛的信息? ?3.?system architecture, design hot-spots, project schedule, and?client deliverables.
D. What Are We Trying to Accomplish Here??

E.? Coverage, Not Testcases?

F. ?Liaison between Design Architect and Design Engineer?

G Quitting on First Error

最后簡(jiǎn)單的總結(jié)一下：
1. The protocol says that when an error?condition is detected, the design must?send a NACK packet.? Should my VC?automatically send NACK too?... No.協(xié)議說(shuō),當(dāng)檢測(cè)到一個(gè)錯(cuò)誤條件,設(shè)計(jì)必須發(fā)送NACK包。應(yīng)該我的VC也自動(dòng)發(fā)送NACK嗎?…不。

2. The design indicates FIFO fullness with?signals “full” and “empty”.? Can my VC?or testcase make use of them to?prevent overflow/underflow?... Yes, but?only if checks are made on them
3. Is it sufficient to limit error injection to ?the scenarios for which the DUT has ?detection capabilities?... No.
4. A design has a register bit that defaults?to ‘0’, and causes the DUT to enter?low-power mode when written with ‘1’. ?Is writing ‘0’ when it is already at ‘0’?important to test?... Yes.
5. Can I snoop the design’s internal clock?to synchronize my VC to?... No.
6. Should I ask myself “what is it I’m trying?to accomplish here?” when embarking?on a new verification task... Yes我應(yīng)該問(wèn)自己“是什么我想完成嗎?“當(dāng)開(kāi)始一個(gè)新的驗(yàn)證任務(wù)……是的

7. Is it my responsibility to ensure that the?design architect and design engineer?are on the same page?... Yes.這是我的責(zé)任,以確保設(shè)計(jì)建筑師和設(shè)計(jì)工程師在同一頁(yè)面嗎?…是的。

8. ?Should I regularly step back from low-level implementation and take a high-level view of the verification effort as a?whole?... Yes.
9. A design draws circles of radius given?by an input parameter.? Is testing a?radius of zero important?... Yes
10. Should I implement coverage on?individual register values?...No.
11. Should I be relying mainly on waveforms?to debug my VC?...No.
12. Is coverage closure more important than?testcase passing rate?... Yes.

13. Is it necessary to allow a simulation to?continue running after it has?encountered an error?... No.



來(lái)自為知筆記(Wiz)

轉(zhuǎn)載于:https://www.cnblogs.com/bob62/p/4050968.html

總結(jié)

以上是生活随笔為你收集整理的Verification Mind Games---how to think like a verifier像验证工程师一样思考的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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