IC验证的经验总结
IC驗證的經(jīng)驗總結(jié)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ----IC驗證工程師的“易筋經(jīng)”
? ? ? ? 有人認(rèn)為我驗證做得很牛，也有人認(rèn)為我的驗證早就丟下了；有人認(rèn)為我發(fā)現(xiàn)了各個項目的不少問題，也有人認(rèn)為我在CMM庫的幾百個問題單大部分屬純凈水。
? ? ? ? 好吧，無論怎樣，我還是把我在驗證中如何發(fā)現(xiàn)和定位Bug的思路稍微描述總結(jié)一下，純屬灌水。以前華仔曾經(jīng)叫我寫過一次，我隨手寫了一點點，這次還是詳細(xì)一點吧，主要分幾點：視角、技巧、思路、經(jīng)驗。這里主要還是共享給驗證的同志們，但對設(shè)計的同志其實我覺得是沒有什么差別的。
一、驗證目的
????????發(fā)現(xiàn)Bug，發(fā)現(xiàn)所有的Bug，或者證明沒有Bug，是驗證存在的唯一目的。無論任何驗證語言、任何驗證環(huán)境、任何驗證方法學(xué)、任何Feature List，都是為了達(dá)成這一目的而使用的方法，或者所手段。偏離了這一目的任何工作和努力，都是屎、大便、Shit。
????????絕對不要被任何華麗的技巧、方法、經(jīng)驗所迷惑，無論驗證環(huán)境有多么美麗，無論驗證語言有多么的High Level，都不要迷惑。不要為了追求完美、高效的環(huán)境而沉迷其中，陷阱往往就在美麗的后面。有時候，最簡單的，才是最直接的，任何武術(shù)，直拳最有效。
????????以SV為例，SV有高層次的語法和結(jié)構(gòu)，能夠更大限度發(fā)揮激勵的控制和Random測試的效率。但是對于發(fā)現(xiàn)Bug的目的而言，它只對其中的20%目標(biāo)達(dá)成有突出貢獻(xiàn)，而剩余的80%，其作用和普通的Verilog并無二致。當(dāng)然，我不是指要放棄SV，因為其有效貢獻(xiàn)的20%工作，是普通Verilog很難或者無法完成的工作。OK，所以順便涉及另一個問題，設(shè)計人員需要學(xué)習(xí)SV嗎？有多少設(shè)計人員能夠在檢視或簡單UT中發(fā)現(xiàn)80%的Bug，而需要SV去完成最后20%？不要看見別人用SV，就屁顛屁顛地跟潮流，想清楚SV能為達(dá)成最終的目的帶來什么貢獻(xiàn)才是關(guān)鍵。設(shè)計人員和驗證人員相互溝通，真正的障礙是驗證方法學(xué)，而不是驗證語言。
????????以TC為例，對于一個驗證人員，跑通全部TC，意味什么？代碼覆蓋率100%，意味什么？驗證差不多完成？在我看來，相當(dāng)于驗證工作大致完成了90%，而有一句老話怎么說的？行百里路，半九十。也就是所，實際上剩下10%，才是最艱辛的工作。也許某條TC什么也沒干，然后因為什么也沒干而Pass了，或者沒有實現(xiàn)驗證者的意圖，所以也Pass了。
只有，而且也只有，有充足信心證明全部Bug被發(fā)現(xiàn)、或者沒有Bug。但這個充足的信心怎樣說明？后面我再詳細(xì)說明。
二、驗證視角
????????有多大的視角，就能發(fā)現(xiàn)多少的Bug。引用CCTV的一句臺詞，心有多大，舞臺就有多大。我比較不喜歡看到的，就是一個驗證人員跑來告訴設(shè)計人員，說某某TC Fail了，波形在XXX，請分析。我不能認(rèn)定這位驗證人員的工作是否合格，只能表達(dá)強(qiáng)烈的情緒，特別是最后發(fā)現(xiàn)Fail的原因是驗證環(huán)境問題的時候。這種驗證人員，對設(shè)計人員、項目經(jīng)理，都是巨大的風(fēng)險。因為設(shè)計和驗證，是一定需要有交集的，并且耦合越大，風(fēng)險越小，只能提Feature、寫TC的驗證人員，就像初三的新月一樣，反而需要別人去耦合，如果設(shè)計人員視野不足，野心不夠，就存在空隙了。
? ? ? ? ?? ??
????????一個驗證人員，如果能夠發(fā)現(xiàn)設(shè)計中的Critical Path并告訴PR，一定不會得到批評，反而會在實現(xiàn)工作中得到更多的發(fā)權(quán)，和更多的發(fā)展。一個驗證人員，如果僅僅只能跑寫TC、跑TC，那么多年得不到晉升恐怕也怨不得別人。OK，回到原點。驗證人員必須要懂得代碼，懂得分析邏輯，甚至能夠通過代碼分析出可能的疑點，更好的，能夠理解整個系統(tǒng)的運作，理解前端后端的實現(xiàn)，找出設(shè)計人員視角的盲區(qū)，才能更好的發(fā)現(xiàn)Bug，解決Bug。當(dāng)然，某些同志會認(rèn)為，驗證人員，發(fā)現(xiàn)實現(xiàn)的問題耽誤了主業(yè)，而且實現(xiàn)的問題，實現(xiàn)人員更容易發(fā)現(xiàn)。OK，這里同樣存在一個視角的問題，你的視角和實現(xiàn)人員的視角是不一樣的，也許覺得很容易發(fā)現(xiàn)的問題，恰好別人不容易發(fā)現(xiàn)呢？反過來說，實現(xiàn)人員或設(shè)計人員還可以覺得代碼Bug對于驗證人員是很容易發(fā)現(xiàn)的呢。此外還有一個時間成本的問題，任何問題，遺留的時間越長，代價越大。
? ? ? ?所以我說一句，驗證人員，一定要放開視角，努力去看你所能夠看到的，然后，你能夠看得更多。然后再補(bǔ)充不務(wù)正業(yè)的說明，驗證人員的目的是發(fā)現(xiàn)Bug，這是唯一的目的，不僅僅是一個TC所能發(fā)現(xiàn)的Bug，而是整個芯片可能存在于任何環(huán)節(jié)、任何位置的Bug。只有芯片的成功，才是真正的成功，而一個Bug，就可以毀掉一個芯片，而覆巢之下，安有完卵？當(dāng)然，驗證人員會問，整個芯片太大了，擴(kuò)展視角，不是不努力，而是看不到啊。OK，我再說一句，對于驗證人員，最簡單，最真切的視角就在腳下。TC，每一條TC，每一個TC的波形，都代表了芯片中的全部或部分，真實運作的場景，有血有肉。如果把波形當(dāng)作TC Pass的附屬物，那么，恭喜，驗證人員，你拿了芝麻丟了西瓜。波形真的可以告訴你很多、很多。
? ? ? ?我甚至可以公布我做驗證的時間分布（不包括最初搭建環(huán)境的時間），20%時間寫TC，10%時間調(diào)環(huán)境，50%時間看波形，確認(rèn)TC達(dá)到我想要的意圖（TC Log中的Pass？噢，對不起，這種狗屎信息我向來忽略），剩余20%時間？對，剩余20%的時間，是我固定的，從當(dāng)前表面上正確運行的波形中，對照代碼，尋找其他可能發(fā)現(xiàn)的時間。
???????不要跟我說現(xiàn)在系統(tǒng)太復(fù)雜，看波形效率太低。OK，Hi1380的系統(tǒng)復(fù)雜不？整個波形我也從頭到尾看過啊。而且，就在我看波形的第一天，就是從一個已經(jīng)Pass的，好像是GIC的系統(tǒng)驗證波形中，拿到了超過20個問題單（加上代碼檢索的30個問題單，創(chuàng)造了下圖中陡升的曲線，不過可惜了，沒能突破300）。
? ? ? ?
三、淘金的執(zhí)念
????????缺陷就在哪里，靜靜地躺在哪里。沒錯，一定在，而且馬上就能看到！！執(zhí)念，這是一種執(zhí)念！！作為驗證人員，一定要有這種強(qiáng)烈的，不可動搖的執(zhí)念或者說饑渴感，而且是和設(shè)計人員強(qiáng)烈對抗的執(zhí)念。
????????實際上，目前看到的所有芯片，都已經(jīng)證明，投片后，依舊有缺陷遺留在其中，沒有被發(fā)現(xiàn)。所以，這種執(zhí)念，無比正確。只有瘋子，才能發(fā)現(xiàn)隱藏得最深的金子。
????????我開始做設(shè)計之后，這種執(zhí)念消失了很多，總是希望系統(tǒng)確實在完美地運行，失敗，很是失敗。不過對他人設(shè)計的模塊，以及不是我負(fù)責(zé)的項目，這種執(zhí)念還是非常強(qiáng)烈，呵呵，這也是我在1380和P600中瘋狂創(chuàng)造問題單的原動力。
????????這跟淘金的人，可能是差不多的。金子就在這里，一切的希望都在這里，再挖一鋤頭，就找到了。只有瘋子，才能成功。
???????????????????????
四、淘金的技巧
????????指定找一塊地，瘋狂地朝下挖？No，No，瘋子都會B4你，淘金也是有技巧的。
????????很多方法，其實說白了，很簡單的。
????????表層的土是最容易挖的，那么，別人沒有挖過的地方，最有可能在表層找到金子。為什么別人沒有挖？很簡單，盲區(qū)。兩種盲區(qū)：
? ? ? ?對于表層土的挖掘，不要太固執(zhí)于一點，廣撒網(wǎng)，多捕魚。如果十鋤頭都沒有挖到金子，馬上換地方，對于別人剛挖過，還沒深挖的地方，也來上幾鋤頭，說不定就可以讓前一個家伙悔到死。
? ? ? ?表層土都差不多了，就需要找關(guān)鍵部分深挖了。如何找關(guān)鍵部分，是非常講究的事情，兼顧風(fēng)水、心理、外交、直覺等多方面知識，很難給出綜合性的分析。下面幾點可作為Hint：
? ? ? ?需要注意的是，在挖掘這些Hint點的時候，并不一定能保證挖到金子，而且即使有金子，你也并不一定能夠挖到，人品，人品很重要。
? ? ? ?OK，關(guān)鍵部分都挖得差不多了，剩余的金子基本上就埋藏得比較深了，這個時候發(fā)現(xiàn)的金子都將比較可觀。再不濟(jì)，也能夠成為榮譽獎、星星獎之類，要搞得恰當(dāng)了，直接拿A也不是夢想。當(dāng)然，如果沒能發(fā)現(xiàn)金子，一無所獲的可能性也很大。
? ? ? ?收益和風(fēng)險是成正比的，淘金人在這個階段一定要能夠沉下心來，冷靜思考。樓上提了這么多Hint，那個地方還比較薄弱？整個項目統(tǒng)觀下來，還有哪里有薄弱的？你在思考，項目經(jīng)理也在思考，驗證經(jīng)理也在思考，SE也在思考。如何超越項目經(jīng)理、SE、驗證經(jīng)理的思考發(fā)現(xiàn)金子？我非常、非常難以回答。提供我已有的兩個經(jīng)驗是：
五、開門紅
????????根據(jù)規(guī)格分解FeatureList，根據(jù)FeatureList對應(yīng)TC，然后再一條一條仿真TC反過來映射FeatureList和規(guī)格。沒錯，這是最通常的做法，可惜我不這樣做。
????????世間有80：20原則，驗證也是，80%的問題都可以通過20%的測試和時間去發(fā)現(xiàn)和解決，而剩余20%的問題需要80%的測試和時間去解決。
????????所以，按照我的思路，會有幾個最初級的TC，可以用來測試最基本的通路能否冒煙，這幾條TC，可以劃歸到TC List中，也可以不劃歸。然后，一定有一條開門的TC，這是一條復(fù)雜的Directed TC，一條可以覆蓋70%的Feature的TC。
????????這條TC并不負(fù)責(zé)任何Corner、異常覆蓋，不做任何特殊的思考，一切都是直接對Feature的連續(xù)描述（也可以是若干條TC的直接串聯(lián)），因此即使有些許問題，修改的難度也比較低。
????????這條TC能夠幫助設(shè)計人員定位超過70%的問題，如果設(shè)計人員足夠聰明，這個TC可以解決90%的問題。
????????這條TC的壽命可能將超過一個月，這一個月足夠設(shè)計人員在其中沉沉浮浮，使得代碼達(dá)到95%的交付情況。而驗證人員在這一個月中，有足夠的時間完善Corner的TC、Random的TC和環(huán)境，然后集中精力完成剩下10%問題的解決。
六、檢視
????????代碼檢視是最容易發(fā)現(xiàn)問題的步驟，從寫第一行代碼開始，到最后一個Tag結(jié)束，都是如此。
? ? ? ? 代碼檢視不僅僅是設(shè)計人員的事，也是驗證人員的事。我知道很多人都不認(rèn)同這樣的觀點，正如我不明白為什么有些掃一遍代碼就能發(fā)現(xiàn)的問題，有些驗證人員還那么興致勃勃、廢寢忘食地編寫TC，然后再辛辛苦苦跑TC來發(fā)現(xiàn)一樣。
????????正因為我做過設(shè)計人員，所以我感受非常深刻，設(shè)計人員絕對都是極度樂觀、自信的，特別是代碼剛剛完成那一霎那，瞬間的快感，Oh，鳳姐啊，芙蓉啊，讓設(shè)計人員全身都在顫抖。破綻啊，這里有太多的破綻了。
????????所以對于新交付的代碼，按照我的經(jīng)驗，建議驗證人員先檢視（尤其是設(shè)計人員是兩年以內(nèi)設(shè)計經(jīng)驗的），不過，這個檢視絕對不要是傻看代碼，要跑一條TC，最簡單的，就一個讀寫就可以了，保存所有信號的波形，然后打開Verilog代碼，對照著波形檢視。
? ? ? ?代碼，是設(shè)計人員思路的直接映射，而設(shè)計人員的思路，有時候真的是一根筋。通過檢視，或者加上設(shè)計人員的講解，可以直接了解一下到設(shè)計人員的思路、邏輯思維模式，非常有助于去構(gòu)造一些檢測其思路正確或不正確的點，驗證人員的思維其實很簡單，抬竹杠就好。
? ? ? ?請讀者回憶一下剛剛經(jīng)歷過的項目，在100%網(wǎng)表之后，是否有好幾個ECO，都是從檢視中出現(xiàn)的（代碼或腳本或TC）。而每一個這樣的事件，都是那么神奇的偶然。可能是某位新員工周末偶然在學(xué)習(xí)老員工的代碼時發(fā)現(xiàn)異常；可能是某人在項目經(jīng)理逼迫下第三次檢視某個模塊時，驚訝地發(fā)現(xiàn)了一個低級錯誤；可能是某個IP交付團(tuán)隊某天突然想起說有一個連接的錯誤忘了改正，但幸好在ECO前發(fā)現(xiàn)。反正，總是奇跡一般，讓項目經(jīng)理覺得自己是世界上最幸運的項目經(jīng)理。明白了嗎？
? ? ? ?我經(jīng)歷的多個項目，每次都有這樣的奇跡，其比例占ECO的約30%～50%，這不是偶然，是一個說不清，道不明的必然。也許，只是100%后，同志們有更多的時間投入檢視而已。怎么能不檢視？檢視，在任何時候進(jìn)行，都不算早，也不算晚。
? ? ? ?OK，這里就扯到另一個話題，某些同志經(jīng)常反饋，檢視工作非常不受待見。不做，沒人管，做了，看不到績效，即使檢視出問題，也會有人跳出來說，“這么簡單的問題啊”，特沒成就。OK，我認(rèn)為這是管理問題，典型的。無論對于海思的投資團(tuán)隊，還是對于項目經(jīng)理本身，用最小的投資，或者說最小的人力、最短的時間，努力去發(fā)現(xiàn)項目中的問題的活動，難度不是最應(yīng)該鼓勵的嗎？OK，如果你真有這樣的感覺，我的建議是，將檢視問題提問題單，再不濟(jì)也是一個嚴(yán)重，發(fā)現(xiàn)階段為ST，不用覺得害臊，害臊的應(yīng)當(dāng)是管理者。
? ? ? ?此外，到最后階段的檢視，對于驗證人員，可能需要更加地擴(kuò)大視角，圍繞代碼為核心，TC、波形、腳本都需要涉及。對于這里，我還是再強(qiáng)調(diào)一遍吧。驗證人員擁有設(shè)計人員所不同的視角，所以一定能夠發(fā)現(xiàn)潛藏在其中的問題，對于單個項目而言，驗證人員會認(rèn)為是一個偶然，而從多個項目而言，我的經(jīng)驗，這是一個必然。
七、檢視的經(jīng)驗
?7.1、這里我可以再補(bǔ)充一下我個人檢視代碼的經(jīng)驗，我的步驟如下
?7.2、我拿我曾經(jīng)的一個模塊Security Engine代碼作為實例，如果我進(jìn)行檢視如何進(jìn)行
八、再談檢視
? ? ? ?首先引用一個對檢視的不同觀點：Review真的最有效嗎or導(dǎo)致更多的BUG?
? ? ? ?Review：中文叫評審。本人見過這個做法的最早出處是朱蘭的質(zhì)量手冊。在很長一段時間被軟件行業(yè)認(rèn)為是最有效的保證代碼質(zhì)量的手段。這段時間的質(zhì)量高壓之下,我們再次見到了紅紅火火的各種代碼vreview，自檢、互檢、飛檢、X檢。這讓我想起了考試，考試完了都要自己檢查幾遍再交卷。(當(dāng)然是在能夠把題目做完的情況下),偶爾我們也會在考場上互檢(不過這個可能屬于作弊)。不過從以上最簡單的例子可以看出,互檢應(yīng)該比自檢效果好很多,不然也不會有很多學(xué)生冒著風(fēng)險去互檢了。
? ? ? ?但是:上周在和敏捷顧問一起參加一個項目組的回顧會議的時候,發(fā)生了這樣一個狀況,大家在討論下輪迭代需要改進(jìn)的時候,都提出來要加強(qiáng)LLT測試用例的review,顧問一直追問我們?yōu)槭裁匆@么做？是不是上輪迭代的結(jié)果出了什么問題？我們這樣做能夠帶來哪些改善？我們的UT一直做得很弱,顧問非常奇怪為什么我們不多花些時間做UT？而要花時間去做LLT用例的review？當(dāng)問到從迭代結(jié)果上除了什么問題而導(dǎo)致我們想加強(qiáng)LLT用例的檢視的時候,大家都找不出直接的證據(jù),只是說:如果不評審,風(fēng)險會很大。(但是上輪迭代的最大問題大家已經(jīng)搞清楚了——是:低層BSP沒有人力投入,導(dǎo)致其中4個相關(guān)的Story無法全部完成。
? ? ? ?我也很詫異顧問提出來這個問題,他繼續(xù)講:review有可能是一種浪費。my lady gaga! 我自己從來沒有聽說過review可能是一種浪費。顧問為什么能夠提出這樣的疑問？
? ? ? ?其實這段時間經(jīng)常會收到不少項目組發(fā)的郵件,宣稱自己團(tuán)隊組織封閉檢視又發(fā)現(xiàn)了幾百個問題,似乎是這樣做還能得到一些表揚。當(dāng)時,我內(nèi)心深處覺得有那么些不對勁,團(tuán)隊1個月的編碼工作,怎么能在短短半天的時間里面就可以檢視出這么多問題？這也許說明了檢視有效,但是是不是更加說明我們前面的工作并沒有做好呢？(再次 Oh,my lady gaga,我自己怎么都對review產(chǎn)生了懷疑。)
? ? ? ?后來忽然在溫伯格(?軟件程序開發(fā)心理學(xué)?、?顧問工作的秘密?等書的作者)的一本書籍目錄中看到了這樣一句話,“任何質(zhì)量措施，益早不益重”。但是非常遺憾,我沒有看到全文,只能根據(jù)這句話來進(jìn)行推測和分析（在信息不完整的情況下進(jìn)行分析是敏捷教練應(yīng)該具備的能力之一——someone said）。
? ? ? ?好吧,我們來看看REVIEW的效果吧。優(yōu)點:review能夠發(fā)現(xiàn)問題。缺點:review無法象測試一樣可以重復(fù)性地保證缺陷沒有被引入。
? ? ? ?另外:我們可以按照下圖方式畫出Review和BUG的系統(tǒng)控制圖：如果我們在如下場景下加強(qiáng)REVIEW，將會進(jìn)入一個非常有意思的循環(huán)：
? ? ? ?加強(qiáng)REVIEW --> 發(fā)現(xiàn)問題 --> 占用了時間 --> 更沒有時間做測試等等 --> 生產(chǎn)更多的問題 --> Review會發(fā)現(xiàn)更多的問題 -->大家認(rèn)為Rvreview很有效果 -->大家會用更多的時間Review --> 于是產(chǎn)生更多的BUG^^^^^^^^^^
? ? ? ?
? ? ? ?神啊，GAGA啊，感謝這些不同的觀點吧，正是有了不同的觀點，才讓我們能夠更加深入討論的機(jī)會。
? ? ? ?在我寫完前一期的經(jīng)驗總結(jié)后，接收到了很多關(guān)于檢視的不同的觀點，很耐人尋味的是，這些反面的觀點，基本上全部來自于從Intel、BroadCom等公司背景的高端同事（當(dāng)然也包括了我引用的這位外籍專家），在這些外來的，充滿魅力、經(jīng)驗豐富的男人們看來，強(qiáng)調(diào)檢視是屬于海思（從引用的專家的指向，整個華為也是如此）的專利，而被人直接用肉眼發(fā)現(xiàn)代碼中的缺陷，簡直就是人生中的奇恥大辱，真正保證設(shè)計正確的，只能是有激勵的仿真。
? ? ? ?其實我非常贊成樓上最好的一個描述，真的，非常贊成。檢視，只是檢視，只是能偶爾地，發(fā)現(xiàn)一些錯誤而已，檢視什么也保證不了，檢視既不能保證Bug被全部發(fā)現(xiàn)，也不能保證這些偶爾發(fā)現(xiàn)的Bug能被修正或不被重犯，更重要的是，檢視根本無法保證設(shè)計最終能夠正確運行，最終能夠保證設(shè)計正確運行的，只有仿真。
? ? ? ?但是，為什么我們常常從檢視活動中受益呢？難道真的如我引用的文字所述，我們也陷入了強(qiáng)調(diào)檢視，而弱化測試，然后檢視出更多Bug，而更加強(qiáng)化檢視、弱化測試的循環(huán)？
? ? ? ?下來后，我進(jìn)行了反復(fù)思考和交流，得出了我的一些觀點，以供參考。OK，我并不是想駁倒前面的觀點或證明什么，不同觀點之間的激蕩間，我相信讀者自有能力分辨和獲取自己的觀點。
? ? ? ?首先，那些經(jīng)驗豐富的男人們，也是會進(jìn)行代碼串講的，他們不把這個算成檢視（我們算檢視），而算設(shè)計流程的一部分。
? ? ? ?OK，這一點點誤解只是一個欲蓋彌彰的借口，呵呵，連我自己都害臊了。
? ? ? ?我真正的觀點之一，是我們的設(shè)計人員，還不夠成熟。在國外，十年甚至二十年經(jīng)驗的編程人員比比皆是，所以，這些經(jīng)驗豐富的男人們，周圍也是經(jīng)驗豐富的男人，而在國內(nèi)，十年或者二十年經(jīng)驗從業(yè)的，只要還沒累死，基本上不是領(lǐng)導(dǎo)就是架構(gòu)師了，寫代碼？還是給新員工鍛煉的機(jī)會吧！所以，我們的代碼，往往都是經(jīng)驗小于3年的人員編寫的。我妄自揣測，在海思內(nèi)部，編寫邏輯代碼（非C、JAVA）超過10萬行的，屈指可數(shù)，超過20萬行的，很可能已經(jīng)絕跡。在這種2～3年經(jīng)驗設(shè)計人員編寫的代碼中，認(rèn)真檢視一下，發(fā)現(xiàn)問題，其實并不是件很難的事。嗯，我并不是在嘲弄我們的設(shè)計人員，因為，一個人的成長，一定是需要經(jīng)歷磨練的，正如《成長的煩惱》所演繹的，沒有人能夠一天就長大。我自信我不是很愚鈍的人，但我也是整整寫了3年的代碼之后，才真正醒悟：一份代碼，在寫完之后，一定要再經(jīng)過一次或多次整理和打磨，才能算完成的；一份代碼，一定要把其有效代碼行，精簡、錘煉到最少、最短、最有效，才能算完成的。前一個月，海思有一位叫聶世瑋的兄臺講過一次Verilog編碼，也是這么個道理，只是不知道有多少聽者真正明白了，不過不明白也沒關(guān)系，再經(jīng)歷幾年磨礪，如果還在寫代碼，就明白了。所以，我們的代碼，還需要檢視。
? ? ? ?我真正的觀點之二，檢視，并不能替代仿真，甚至不能讓整個仿真的動作有任何減少，但檢視確實能夠縮短整個仿真的收斂時間。因為，我們設(shè)計人員不成熟的同時，驗證人員同樣不成熟。我看過太多的驗證人員，隨機(jī)向量跑出來一個Bug，然后和設(shè)計人員抱著顯示器追波形，太陽升起，然后落下，再升起，再落下。如果定位并解決一個Bug平均需要半天（真不算慢，雖然那些經(jīng)驗豐富的男人們認(rèn)為這只是分分鐘的事），那么一個設(shè)計如果有40個Bugs（不是夸張，比這數(shù)字高的多得要命），光定位就花掉了20天，還不算期間項目組例會、設(shè)計組例會、驗證組例會、攻關(guān)組例會等等的時間。真是累啊，不是兄弟們不努力啊，而是敵人太兇殘啊。所以，我們要檢視，只要通過一整天的時間檢視，能夠發(fā)現(xiàn)其中1/4的Bug，就賺大發(fā)了啊。當(dāng)然，檢視發(fā)現(xiàn)的問題，一定是需要仿真再覆蓋確認(rèn)的，仿真的工作，提取Feature，寫TC，一個都少不了，但定位和回歸，可以大幅縮短。
? ? ? ?我真正的觀點之三，檢視，能夠偶然發(fā)現(xiàn)某些仿真遺漏的重大問題，對，是偶然。但是，我也曾經(jīng)說過，一次是偶然，兩次是偶然，三次就是必然。驗證空間是無限大的，而如何使用有效的仿真覆蓋無限的空間，我們依舊經(jīng)驗不足。所以，這里還是有檢視的空間。
? ? ? ?基于觀點一、二、三，所以我認(rèn)為，檢視，能夠很大幾率縮短項目收斂時間，并發(fā)現(xiàn)一些隱蔽的問題，頗具投資價值。
? ? ? ?檢視很重要，但千萬不要迷戀檢視。檢視的成功，是典型的不可復(fù)制型。所以，檢視，可以成為流程中的一個步驟，但絕不是流程中用以保證結(jié)果正確的方法，換句話說，我們可以定義一個設(shè)計需要檢視多少次，但絕對不應(yīng)當(dāng)定義這個設(shè)計的Bug，有多少比例應(yīng)當(dāng)在檢視中發(fā)現(xiàn)。因為，影響檢視效果的因素太多了，天時、地利、人和，缺一不可。某位檢視人員前天和老婆吵架了，或者會議室空調(diào)太冷，都可能使得檢視效果發(fā)生天翻地覆的變化，所以，不可依靠檢視。如果檢視效果不佳，一切還是只有靠仿真。
? ? ? ?這里，再共享一個我檢視的經(jīng)驗。我把檢視分為私下單P的檢視和會議室中的群P的檢視，單P的檢視，一定要結(jié)合波形進(jìn)行，后面專門講，這里講群P，群P的大部分時間，我都是精神不振的，因為一群大男人聚在一個小屋子里，實在沒啥好雞動的。等待，耐心等待，一旦講解代碼的設(shè)計人員語速放慢了，或者出現(xiàn)遲疑了，發(fā)出了例如“嗯”、“這個”之類的拖延時間的助詞，馬上提問，要求講清楚，不清晰的地方反復(fù)提問，要追根究底，飛流直下三千尺，語不驚人死不休。能確認(rèn)的，現(xiàn)場就可提單，有疑問的，下來對照波形Check。
? ? ? ?最后，Remember，我們的目標(biāo)只有一個，發(fā)現(xiàn)Bug，檢視只是實現(xiàn)這個目標(biāo)的一個手段而已。刀在手，是屠夫還是俠客，存乎一心。
九、重要的是人
? ? ? ?項目是人做的，設(shè)計是人做的，驗證也是人做的。IT行業(yè)，是人的行業(yè)，是創(chuàng)造的行業(yè)，工作是以有效性，而不是以記件式來衡量。工作就必然是受到個人影響的，具體個體特征創(chuàng)造活動。
? ? ? ?所以，重要的是人。
? ? ? ?我的觀點一，讓合適的人做合適的事情，以及合適的搭配和互助。OK，我承認(rèn)這是Absolutely的空話，所以我只能貢獻(xiàn)一下我自己的經(jīng)驗。我個人比較討厭從上到下強(qiáng)制的任務(wù)分配，雖然有時候這是緊急或迫不得已的，并且服從團(tuán)隊的利益，也是一個合格工程師的必備品質(zhì)，但我還是希望，在大多數(shù)時間，能夠讓任務(wù)被自發(fā)的分配。我在曾經(jīng)負(fù)責(zé)過的團(tuán)隊中通常都會這樣去做（當(dāng)然我的團(tuán)隊都非常小，最大8個人），在組建團(tuán)隊后的磨合和學(xué)習(xí)階段，反復(fù)強(qiáng)調(diào)項目目標(biāo)，鼓勵所有人都去熟悉和了解整個任務(wù)的全部環(huán)節(jié)，并以項目經(jīng)理的角度去思考。這樣，需要承擔(dān)的任務(wù)及將自發(fā)被團(tuán)隊成員所分解和理解，然后，在對整個項目的理解過程中，人員的特質(zhì)將被識別，某些成員會退縮，會自發(fā)開始進(jìn)行自己最為熟悉和有把握的工作，這與自發(fā)展開架構(gòu)或ST的工作的，或主動承擔(dān)難度較高或較繁瑣的工作的成員，同樣值得鼓勵，而依舊疑慮并無法熟悉系統(tǒng)的成員，如果樂于被分配到模塊級或簡單繁瑣工作，也是應(yīng)當(dāng)鼓勵的。我的實際經(jīng)驗上并不會出現(xiàn)任務(wù)難以分配或爭搶的局面，因為在相互討論和學(xué)習(xí)的過程中，團(tuán)隊成員之間也會有相互之間的了解和欣賞，所以實際分配任務(wù)時，成員之間會默認(rèn)某些工作更加適合于某人承擔(dān)，并且我常常還會主動混淆任務(wù)的分割，使得某些任務(wù)的邊界部分被多個成員承擔(dān)，至少感覺上，這樣有利于任務(wù)在出現(xiàn)空隙的時候，其相關(guān)的同志能夠更加順暢和自然地提供幫助。當(dāng)然整個過程并不是完全隨意的，項目的目標(biāo)強(qiáng)調(diào)非常重要。此外，某些成員，例如眼高手低，或者非常內(nèi)向的，能夠被識別出來，并在項目過程中及早關(guān)注，也是非常必要的。除了任務(wù)，還要盡量撮合合適的人員進(jìn)行驗證和設(shè)計的搭配。也許是我個人的錯覺，長期坐在一起的同事，或者居住在一個區(qū)域共同做班車的搭檔，往往搭配起來能夠更快完成任務(wù)的收斂。我覺得順暢的溝通和理解，在其中起了很大的作用，在管理中，溝通可以建立，理解難以達(dá)成。所以，我會傾向于讓工作和生活上的伙伴來搭檔設(shè)計和驗證，并且，這也是在任務(wù)分配中常常自發(fā)出現(xiàn)的。
? ? ? ?從我觀點一來看，我傾向建立完全自發(fā)型的人員組成，強(qiáng)調(diào)團(tuán)隊的目標(biāo)，并使團(tuán)隊內(nèi)的任務(wù)相互交叉，鼓勵生活和工作的伙伴搭配完成任務(wù)。OK，說到這里，我承認(rèn)我其實非常的膚淺，雖然我一直有這樣的意愿，并一直努力這樣做，但真正的理解和把握是相當(dāng)薄弱的，沒法給出更多的總結(jié)。
? ? ? ?我的觀點二，針對驗證人員，建議不要僅僅按照驗證的流程一步一步執(zhí)行，而要針對同伴量體裁衣。不同的設(shè)計人員，有不同的特征的。粗心的、內(nèi)向的、喜歡忽悠的、身兼多職的，識別出來并不困難。對于粗心的設(shè)計人員，可以集中力量在前期檢視，迅速發(fā)現(xiàn)其大量Bug，通過交付規(guī)范的制定，推動其返工，幫助其重新細(xì)致思考；對于內(nèi)向的，則需要四面出擊，多多幫助其和周邊、上下游溝通，特別避免因為信息不暢而出現(xiàn)的規(guī)格遺漏、需求理解錯誤、前后數(shù)據(jù)接口的握手等地方，所以Feature的整理和澄清需要很多時間；對于喜歡忽悠的（自信心膨脹的設(shè)計人員往往都是如此），就需要沉下心來，反向推敲其思路，著重在Corner和強(qiáng)反壓的隨機(jī)測試中；對于身兼多職的，其交付、溝通等多個環(huán)節(jié)都可能會出現(xiàn)遺漏，所以驗證人員應(yīng)當(dāng)更進(jìn)一步，主動承擔(dān)某些設(shè)計人員應(yīng)有的工作，不要說nLint，幫助設(shè)計人員理解協(xié)議、分析代碼、修改代碼，也不是不可以的。也許這些事情，并不在流程中被標(biāo)識，但伙伴，就一定要能夠相互扶持、共同進(jìn)退。一對搭檔，共同的成功才是真正的成功。
? ? ? ?我的觀點三，項目經(jīng)理（或驗證經(jīng)理），建議在看測試報告的同時，也要看人。即使都是符合交付流程的測試報告，不同的人交付，其背后的含義都是不一樣的。新員工往往注重形式而不清楚其內(nèi)涵，老員工往往以完成為目的而不注重形式，有的同志會忽視條件覆蓋率而只關(guān)注TC和代碼行的覆蓋，有的同志思考問題過于理想，以至于主動避開一些Corner Case，還有的同志重隨機(jī)而輕直接，或重直接而輕隨機(jī)。這些都是需要進(jìn)行識別和分析的。流程解決不了這些問題，即使包括評審，親身經(jīng)歷。如何進(jìn)行識別呢？我的一個建議是做對比，將多份報告同時打開，多份驗證環(huán)境同樣打開，相互對比，分析其中的差異。這一點，在流程中，是沒有的，而且，基本上，驗證人員本身也都很少主動進(jìn)行這種對比的。
? ? ? ?算了，寫不下去了，以上內(nèi)容均為廢話。很多內(nèi)容，只是我個人的一種Feeling。我只是覺得啊，流程，只是指導(dǎo)人正確的做事情，卻往往沒有辦法保證人能夠?qū)⑹虑橥耆稣_，能把事情做正確的，最后還是人。所以啊，很多內(nèi)容，實在沒有辦法整理清晰并總結(jié)成文字，嗯，回頭看整篇文字，也很是沒有條理，唉，原諒我吧。
十、測試數(shù)據(jù)會撒謊
? ? ? ?測試數(shù)據(jù)會撒謊，沒錯，測試數(shù)據(jù)會撒謊。
? ? ? ?當(dāng)黑暗蒙住雙眼，迷途的羔羊啊，如何才能追隨上帝的步伐。
? ? ? ?當(dāng)信息不能最直接顯示，而需要通過其他現(xiàn)象推導(dǎo)或表現(xiàn)，并且人數(shù)超過3個的時候，則測試數(shù)據(jù)會撒謊。
? ? ? ? 這種情形，主要出現(xiàn)在FPGA測試和樣片測試中。當(dāng)問題出現(xiàn)在這兩種測試環(huán)節(jié)中時，現(xiàn)象往往都非常表面，虛得很，就像浮在水面上，而真正的Bug，往往潛伏在深邃的水底，而水面上，還經(jīng)常有浮萍啊、烏龜啊，或者紫金礦業(yè)的污染物啊之類的阻擋，要像EDA驗證一樣，啪嗒一下直接找到問題（EDA我們往往都沒法啪嗒），其難度，不亞于逮住看貼不回帖的潛水艇。
? ? ? ? 所以，我們往往會收集各種測試數(shù)據(jù)和現(xiàn)象，進(jìn)行分析，甚至投入巨大人力，成立攻關(guān)組。這些收集的數(shù)據(jù)和現(xiàn)象，以我已有的經(jīng)歷看，其中10%～20%是謊言。這里，并不是有測試或攻關(guān)的兄弟有意在欺騙大家，嗯，絕對不是，兄弟們可都是老實淫啊。記得有這么一個笑話，一個GG問一個PPMM
“你是處女？”
“不告訴你，你是？”
“我天枰！”
“……”
- 1
? ? ? ?就是醬紫，明白了吧，當(dāng)本身不是清晰源頭的信息，在匯總和整理時，一定會存在理解上的偏差。這種偏差的引入，我所見，有如下幾種可能：
? ? ? ?所以，對待測試數(shù)據(jù)，特別是FPGA和樣片測試數(shù)據(jù)，要有自己的想法。
? ? ? ?曾經(jīng)，有一個項目（不是P600），為定位一個樣片測試還是FPGA測試的問題，投入數(shù)人、數(shù)周，方法思考定位，搞得大家的衣服都變胖了。最后卻發(fā)現(xiàn)，一個最初的測試現(xiàn)象是假象，而以此引申出的后續(xù)所有分析和論證的現(xiàn)象，是錯誤的。具體是哪一個項目，到底是哪一個問題？我現(xiàn)在都已經(jīng)完全想不起來了，但那種強(qiáng)烈的挫敗感和失意感，在我的腦海中，久久揮之不去，唉，問君能有幾多愁，恰似一群太監(jiān)上青樓。所以，要有自己的想法。樣片測試和FPGA測試，對于所有測試現(xiàn)象和數(shù)據(jù)，要有自己的想法。
? ? ? ?最后，切記，最終真相只有一個，上帝會擲骰子，但不會在芯片內(nèi)部擲。IC之神，關(guān)羽、張飛，都是實在人，任何缺陷，任何問題都有其唯一的原因的，一便秘就怪地球沒引力是沒有道理的。認(rèn)真分析、思考，要有自己的想法。
十一、波形為王
? ? ? ?波形不撒謊，這是我做驗證的格言。
? ? ? ?波形是真理，可以擊破一切虛假、迷亂的謊言。
? ? ? ?波形，是一個邏輯正確運行的最直觀的體現(xiàn)，是邏輯在每一個時鐘沿，觸發(fā)每一個信號的跳變或不跳變，進(jìn)而產(chǎn)生美麗的，如波浪般運轉(zhuǎn)的脈動。
? ? ? ?中醫(yī)看病，講究的是，望、聞、聽、切，驗證看波形Check缺陷，正如中醫(yī)診斷的切脈診病，除非醫(yī)術(shù)達(dá)到精深廣博，否則僅靠望、聞、聽斷病，是不夠的。
? ? ? ?規(guī)格是人寫的，詳細(xì)設(shè)計是人寫的，激勵是人寫的，RM是人寫的，自動比對及Log打印也是人寫的。在做過的幾個項目中，我無數(shù)次得看到這些內(nèi)容在編寫和理解的過程中出現(xiàn)誤差，而導(dǎo)致最終的結(jié)果和實際不符，期間誕生了多少的磨難。。。。。。。正是經(jīng)歷了太多的磨難，我最終成為了一個驗證原旨主義者，任何可以提升驗證效率的自動化工具，我都會首先進(jìn)行排斥，即使使用也充滿疑慮。跟我共事過的兄弟應(yīng)該比較了解了，呵呵，這和轉(zhuǎn)載我文字的接入的傅曉兄弟幾乎是南轅北轍的兩極。因為我始終認(rèn)為，自動化雖然提升了效率，但是自動化屏蔽了非常多信息，如果驗證的員工對驗證的根本性質(zhì)理解不足的時候（特別是新員工），這種屏蔽非常有害，并且常常容易將錯誤隱藏起來，而這種隱藏，比效率低下更加致命。所以我始終認(rèn)為，某些效率提升所帶來的收益，是小于問題被遺留到最后才發(fā)現(xiàn)所造成的損害的，雖然，這不符合公司效率提升的導(dǎo)向。例如SV，我認(rèn)為，在沒有理解驗證理念和方法之前，連《Writing Testbench》都沒有看過兩遍（注意，是兩遍），還沒明白驗證不僅僅是跑TC之前，就開始玩SV的Class，有害無益（所以我是DT003做SV最堅決的反對者，很多新員工，甚至連OOP是啥都不知道）。想想我們自己是怎樣前進(jìn)的吧，從Verilog到Vera、SystemC、SV，一步步走來，經(jīng)歷了多少磨難。我看到有太多的，這兩年新進(jìn)的員工，表面上什么都知道、什么都會做，但在需要沉下心來分析和理解的問題上，卻屢屢碰壁。所以，直至今天，我推崇，絕大部分工作，采用最原始的純手工方式打造，包括設(shè)計和驗證。我寫的RTL代碼，都是手工一行一行敲入的，我所驗證的邏輯，都是一個一個波形Check的。我沒有覺得自己效率非常差，反而樂在其中。呵呵，其中的樂趣，是那些只看Log，忽視波形的人可能無法體會的了。正如“向前一小步，文明一大步”這種長短之間的哲理，女人永遠(yuǎn)無法理解一樣。
? ? ? ?呵呵，當(dāng)然，我上面這一觀點并不適用于任何人，應(yīng)該會有很多兄弟拍磚的。
? ? ? ?波形，反映的是邏輯運行的規(guī)律，是最切近于最終芯片工作狀態(tài)的表現(xiàn)。波形中的每一個時鐘脈沖，每一個毛刺，每一個Delay，都將最終完完全全映射到最終的芯片中（特別是后仿）。所以，看波形，能夠最真切地發(fā)現(xiàn)芯片實際運行中可能的缺陷和風(fēng)險。作為一個經(jīng)歷過三個項目的項目經(jīng)理，我特別建議項目經(jīng)理（其實包括所有有責(zé)任感的工程師）能夠多看看波形。每一顆芯片，項目經(jīng)理在其中經(jīng)歷了多少的艱辛和風(fēng)險，實在不足為外人道。所以，每一顆芯片，對于項目經(jīng)理而言，都是一個珍貴的孩子，能夠在它出生之前，觸摸它的每一次心跳，感受它的血管的流動和神經(jīng)的傳導(dǎo)，是多么的難以言語的經(jīng)驗。所以，最近的三次項目，我都承擔(dān)了后仿的相當(dāng)一部分工作，我會精心地Check每一個時鐘和復(fù)位，在最典型的激勵下，仔細(xì)的檢查各個模塊之間的數(shù)據(jù)流交互，還有每一個IO的延遲和時序，因為我知道，在波形中我看到的，就是最終芯片運轉(zhuǎn)的情形，所以我一定會盡我最大的心力去保護(hù)它，毫不留情地去除掉任何一個可能會影響其健康成長的因素，讓它能夠健康出生、健康成長。為人父者，無它，其責(zé)必重，其謀必遠(yuǎn)，其心必仁，而其言行必慎！總此四德，天下為父者不可不遵也！
十二、怎樣追波形
? ? ? ?曾經(jīng)，有同事仿真掛死，抱著顯示器看波形，看了兩天，沒有結(jié)果，給我，我看了30分鐘，找到了原因；曾經(jīng)，在同事已經(jīng)仿真Pass，最簡單的中斷測試波形中，我找到了超過20個Bug（和中斷測試無關(guān)）。所以有同事問我怎么做到的，所以引出了我寫這個連載。在這個連載的最后一節(jié)，我最后分享一下，我通過波形發(fā)現(xiàn)問題，及問題的原因的一些經(jīng)驗。
?12.1、一回生，二回熟
? ? ? ?很多新晉的驗證人員抱怨，這么多信號，這么復(fù)雜的連接關(guān)系，千頭萬緒，眼睛都看得長挑針，還是看不出東西。OK，我說，這是沒辦法的事情，看波形，追波形，是一個經(jīng)驗積累的過程，任誰都逃不掉。爺爺都是從孫子走過來的。越是看，越是明白，越是不看，越是不懂。看得多了，自然就知道應(yīng)該抓那些信號，如何分類，如何追溯了。所以我奉勸某些希望通過全自動的Log和信息推導(dǎo)結(jié)果，或者每次一有問題就找設(shè)計人員看波形的驗證人員，回頭是岸。波形，是邏輯運行的最真實的表現(xiàn)，逃不掉的。為什么我看波形快？無他，唯手熟爾。
?12.3、先看X和Z
? ? ? ?任何一個波形，無論是驗證的前期、中期、后期，到手之后，先刷屏，找X和Z，確認(rèn)，某些Z和X是可以存在的，例如某些IP模型，或者未初始化的寄存器和RAM，但芯片開始正常后，Z和X，都不應(yīng)當(dāng)存在。OK，我承認(rèn)這個經(jīng)驗非常簡單，某些高層領(lǐng)導(dǎo)可能認(rèn)為這簡直就是幼稚。可惜，可惜的是，我至今為止看的，所有項目的波形，都能夠在這上面找到Bug，甚至我可以預(yù)計下一個項目，我繼續(xù)看波形，還是能夠找到。以我自己設(shè)計的L2 Cache為例，一個多年驗證經(jīng)驗的老員工負(fù)責(zé)驗證的，至今已經(jīng)在多個項目中量產(chǎn)，還是在最近檢查波形的時候發(fā)現(xiàn)有一個文件wire聲明時把信號名寫錯了，懸空了（因為該信號是input，隱含了wire聲明，所以不影響功能）。OK，X和Z，一定會存在，第一時間找到它，可以節(jié)省非常多的驗證定位時間，否則追波形半天發(fā)現(xiàn)是X，真是浪費青春。X和Z，所對應(yīng)的Bug，可能有如下幾種：
?12.3、再看時鐘
? ? ? ?很多驗證人員不看時鐘。經(jīng)過我反復(fù)的證明，這是一個非常正確的結(jié)論（經(jīng)常在項目驗證后期協(xié)助定位時鐘不對齊導(dǎo)致的環(huán)境問題）。只要TC能夠打印Pass，很多驗證人員不關(guān)心時鐘是否有問題（甚至很多新驗證人員，根本不明白? Delay的概念）。大多數(shù)情況下，時鐘不會有問題？No，大多數(shù)情況下，系統(tǒng)驗證，時鐘都有問題。記得以前在一個項目中推動CRG設(shè)計定義了一個規(guī)范，時鐘分頻寄存器，延遲0.2ns，其他寄存器，延遲0.3ns，分頻的原時鐘，在輸出前延遲0.2ns對齊，不知道看到本文的，數(shù)字平臺部的驗證人員，有多少能明白其中的用意?不解釋，不明白的請自行蹲墻角反省。再想起一個以前海思的設(shè)計規(guī)范，要求寄存器賦值，不可加延遲，也是讓人在風(fēng)中凌亂啊。下面這個邏輯，寄存器賦值沒有延遲，仿真能正常工作否？答案是可以！如果上帝比較仁慈，或者驗證人員對仿真器的always執(zhí)行順序無限了解。
always @ (posedge clkx2)?begin
??clk <= ~clk;
end
always@(posedge clkx2)?begin
??b<= a;
end
always@(posedge clk)? begin
??if(clken) begin
c <= b;
end
end
- 1
? ? ? ?所以，在看完X和Z后，要將所有時鐘拉到波形中Check，看是否所有同步時鐘（包括1：N倍頻）的時鐘沿是否嚴(yán)格對齊，CLKEN時鐘能夠正確將倍頻時鐘上升沿罩住，關(guān)鍵地方寄存器賦值是否有Delay（如果時鐘間不存在? Delay，寄存器賦值可以沒有Delay）。別小看這個工作，Pxxx驗證組，記得哥當(dāng)時被抓去協(xié)助定位了多少時鐘問題嗎？賠我青春損失費啊。。。。。。。。
? ? ? ?OK，我們進(jìn)入正題，怎樣看波形。沒錯，樓上都是廢話，誰再讓我看波形，結(jié)果是上面兩種情況，我就要發(fā)飆了。
? ? ? ?如何在一個看似無限復(fù)雜的掛死波形中定位根因？
? ? ? ?如何在后仿波形中發(fā)現(xiàn)可能的問題？
? ? ? ?如何在表面上沒有問題的波形中發(fā)現(xiàn)問題？
? ? ? ?面對波形，首先要端正心態(tài)，不要認(rèn)為看波形是浪費時間，也不要因為一時無法發(fā)現(xiàn)其中的問題而焦慮煩躁，更不要盲目樂觀，認(rèn)為已經(jīng)沒有任何問題。要執(zhí)著、堅定，充滿勇氣。
? ? ? ?先不要看波形，對，先不要看，這是我很重要的經(jīng)驗之一。要先思考，我的做法是對照架構(gòu)圖，虛擬一個芯片運轉(zhuǎn)的場景，即在腦海中想像一下當(dāng)前這個激勵下，波形應(yīng)當(dāng)是怎樣運作的，激勵怎樣進(jìn)入系統(tǒng)，然后怎樣完成協(xié)議解析和轉(zhuǎn)換，怎樣到達(dá)了總線，然后出現(xiàn)DDR的吞吐，然后CPU取指、取數(shù)，完成處理。OK，也就是說，先要在心中預(yù)留一個完美的Scenario，設(shè)想一下白雪公主和王子是怎樣在城堡中幸福生活在一起的。
? ? ? ?心中有了虛構(gòu)的波形后，再使用Verdi打開波形。抓關(guān)鍵信號，分組，標(biāo)識不同顏色，這些奇技淫巧應(yīng)該不用多說，很多兄弟都比我這個驗證原旨主義者來得厲害。只是需要說明的是，抓多少信號，怎樣分組，很需要斟酌。其實原則只有一個，讓盡可能精煉的信號在一屏內(nèi)顯示，這和代碼的精簡是一個道理。信號除了按功能分類，還要按信息量分權(quán)重。所以還是要說，很多驗證人員，用著花哨的手指技法，一屏一屏的信號抓，刷刷幾屏下來，跟瀑布一樣，很是壯觀，往往Group的數(shù)量比我總共抓的波形數(shù)量還要多。操，看個AXI總線，把a(bǔ)rlock信號和arvalid信號一起抓出來，除了催眠看波形的人之外，有其他意思嗎？以AMBA總線為例，APB先看PADDR、PSEL、PENABLE，AHB先看HADDR、HTRANS、HREADY，AXI先看各個通道ADDR、VALID、READY，如果這些信號不能說明問題，再逐步增加輔助信號觀察，盡量保證在一屏中顯示所有有效信號，如果信號太多，寧可刪除部分。
? ? ? ?然后，將展開的波形和腦海中已有的場景進(jìn)行對照，看數(shù)據(jù)流是否按照腦海中預(yù)期的構(gòu)想而流動。一般來說，實際波形和預(yù)想都不太能夠?qū)ι?#xff0c;最開始的大多數(shù)情況下，波形是正確的，而腦海中的預(yù)想存在不足，這主要是因為我自己對架構(gòu)的細(xì)節(jié)理解還不充分，對某些特殊邏輯處理方式不熟悉，或者某些邏輯相互連接后新增的耦合關(guān)系不了解等等原因?qū)е隆６@個時候，在我看來，也正是一個最好的時機(jī)，來進(jìn)一步熟悉和理解芯片真實運轉(zhuǎn)流程，彌補(bǔ)自己對系統(tǒng)結(jié)構(gòu)、互聯(lián)設(shè)計中各個細(xì)節(jié)的理解不足。在對細(xì)節(jié)的進(jìn)一步理解和澄清的過程中，我會逐步修正心中虛構(gòu)的波形，使其逐漸接近真實的運作。當(dāng)然，在修正過程中，會出現(xiàn)某些確實表現(xiàn)異常的波形，一些明顯出乎設(shè)計預(yù)期的時序出現(xiàn)。OK，這是一個岔路口，先記錄*.rc波形現(xiàn)場，然后對該出乎意料的時序進(jìn)行進(jìn)一步深入追溯。正如前面所述，我常常在已經(jīng)Pass的波形（或后仿波形）中發(fā)現(xiàn)Bug，通常都是從這樣的岔路口開始的。也許這個岔路口最終證明邏輯沒有問題，還是細(xì)節(jié)理解不足導(dǎo)致，但也許就是一個芯片難以發(fā)現(xiàn)的致命缺陷。
? ? ? ?看到這里，也許有同志會問，掛死的波形呢？怎么還沒追掛死的點呢？Yes，就是還沒開始，無論是掛死的波形，Fail的波形，還是Pass的波形，在其實際波形和我大腦中虛構(gòu)的波形沒有完全吻合之前，我是不會開始定位問題的。這簡直是浪費時間？嗯，在最開始定位的階段確實如此，但在驗證進(jìn)入中后期之后，正常的波形和我虛構(gòu)的波形已經(jīng)調(diào)頻到一個波段了，或者說，我已經(jīng)確認(rèn)白雪公主和王子開始幸福生活了。和波形到手，從前到后一掃，尋找那些地方異常，例如，白雪公主生下來的小王子永遠(yuǎn)長不高，那明顯就是有問題嘛。然后，半小時發(fā)現(xiàn)問題，并不困難。當(dāng)然，還是要說，我的經(jīng)驗，是不適合那些平時就只看Log，忽視波形的人的。
? ? ? ?最后，我還是共享一些我定位復(fù)雜掛死波形的根因的經(jīng)驗。起點，定位掛死的起點在那里？或者說，從那里開始追？很多同志認(rèn)為尋找一個合適的起點很重要，或者說最好直接就找到引發(fā)掛死的點。我說，No！！找到直接引發(fā)掛死的點，或者和該點直接相關(guān)的起點，是很困難的，我不做這種類似分析雙色球中獎率的事情，任何掛死的波形，第一時間能夠獲得的信息，都是表象。我會將任意一個被阻塞的操作作為起點，開始我溯溪的旅途（請確信，無論那個溪流，最終都會匯到唯一的源頭）。如有可能，用筆在沿途做下記號，保證在偏離方向的時候能夠返回。溯溪的路途有艱辛、險阻，我看過太多的兄弟在中途放棄，或另尋他路，而有時候，他離最終的源頭，僅一步之遙，所以，最后一個建議，請保持一顆堅定和勇敢的心。有一首我喜歡的歌，范瑋琪的《最初的夢想》，艱難的時候，可以聽一下。
十三、最最后，再補(bǔ)充一點后仿定位的思路，供參考
總結(jié)
- 上一篇： 我的2018：用一年的时间写一份年终总结
- 下一篇： c语言写rpg游戏,第1章 序（来，我们