|
在學校時就對IC有著濃烈的興趣，畢業后也如愿做了IC驗證工作。經過2年的學習和實踐，對驗證的理解零零散散也有不少，但總沒法形成一個比較完整全面的經驗談。這里把我對驗證的一些想法記錄歸納，由于理解有限，下面的篇幅也許會比較零散。 1 驗證對于IC的重要性 IC是集成電路的縮寫，也就是我們常說的芯片；IC行業的技術門檻高、投入資金大、回報周期長、失敗風險高，做一款中等規模的芯片大致需要10多人做1年半，開模的費用一般都在幾百萬，設計過程的筆誤或者設計bug至少都會有上千個，由于設計缺陷或者工藝缺陷很容易造成芯片完全變成所謂的石頭，而如果要重新頭片不但需要投入額外的費用，更會將芯片上市時間延后至少半年，這些風險對于商業公司來說都是不可接受的。 正因為芯片的高風險，才凸顯了驗證的重要性。在流片之前，通過驗證人員的驗證活動發現所有的設計bug，這就顯得特別重要。 2 驗證的一目標 做驗證首先要明確我們做IC驗證的目標是什么。上面我們已經提到，由于芯片的高風險、高代價，才更突出了驗證的重要性，尤其是芯片規模越來越大，邏輯越來越復雜。 為了保證芯片的成功，驗證唯一的目標就是發現所有的bug，做到無漏驗、零漏測。 3 驗證的兩問題 作為驗證人員，首先要搞清楚兩個問題： 1）我們要驗證什么？ 2）我們該怎么驗？ 這兩個問題是驗證的根本，就如同哲學里的“我是誰、我來自哪兒、我要去哪兒”一樣，“我們要驗什么？”是給我們指明目標，”我們該怎么驗？“則是告訴我們該采用什么樣的手段去達到這個目標。 如果這2個問題都沒搞清楚，那么沒人對你負責驗證的模塊有信心，畢竟你自己都不知道你的目標是什么，不知道該怎么做才能達到那個目標。這兩個問題是驗證的核心所在，如果想做好驗證，這是前提。 4 驗證的三板斧 要想做好驗證，保證無漏驗、零漏測，以下三個要素是必須要具備的：驗證工具的掌握、算法/協議的理解、驗證的意識。 1）驗證工具的掌握 驗證工具包括vmm/uvm等驗證方法學、sv/sc等驗證語言、vcs等驗證仿真工具、perl/python等腳本語言，這些東西是做驗證要掌握的基本技能，不論你做什么樣的芯片都需要這些東西來支撐你的驗證工作。 這些驗證工具可以幫助你解決“我們該怎么驗”這個問題，當你很好的掌握這些驗證工具后，你可以有很多種方法途徑去達成你的驗證目標。 說實在話，驗證工具的東西很多，要想在短時間內全部掌握也不可能，而且很多工具可能在你的驗證過程中不會用到。 個人對驗證工具的一點感悟是：不要貪求全部掌握，你可以先看書學習實踐，把這些東西都學習一遍；在學習的過程中你肯定會發現一些好東西（原來還有這種方法可以讓我的xx做的更好）；對于那些暫時不知道怎么應用到實踐中的東西，你也不要認為它們是沒用的，其實只是你不知道用在哪兒而已，在你以后的驗證中也許就會發現它的應用場景，當你需要它的時候也許你已經忘記怎么用了，這個沒關系，你可以再回去查閱資料，這個相信很快就能解決的，這樣有個好處是當你碰到可以用xx的時候你至少能想起曾經看到某個東西可以來實現它，如果你從未學習過，那么你根本就不會想起有這么個方法可以解決它，這才是可怕的，我都不知道這個問題是可以被解決的。 2）算法/協議的理解 芯片要實現什么，不外乎是xx算法、某某協議，算法/協議才是芯片的魂。驗證其實也就是驗的算法/協議實現是否正確。就跟批改作文一樣，只有批改者有一定的文學功底，才能更好的評判作文水平。 因此，驗證人員對算法/協議理解越深刻越好，要理解算法的原理以及算法的實現結構，只有這樣才能找出其中的corner點。 3）驗證的意識 驗證的意識究竟是什么，其實我也說不清楚，只能按照我自己的理解寫寫一些。 · 對任何東西都要有質疑的態度 · 手要伸長，延伸到上下游 · 對問題要刨根問底 5 驗證的流程 做任何事情都需要按照一定的流程來走，否則很容易陷入混亂之中，尤其是對于剛入門的新手來說更是如此。我目前接觸的通用流程大致如下： 1）提取測試點，明確驗什么 · 分析FS/浮點平臺，提取芯片的規格及測試點； · 分析AS/定點平臺，提取測試點； · 分析DS，提取測試點并識別asic與算法的不一致點； 2）制定驗證方案，明確怎么驗 · 刷新測試點列表，明確測試點的覆蓋方式：功能覆蓋率、代碼覆蓋率、直接用例； · 驗證環境的搭建策略，這個步驟是可以做成自動化工具的； · 驗證的重點難點，提前識別重難點，并制定相應的對策； · 刷新用例列表，明確測試用例的方法及步驟； 3）用例執行，隨機測試，發現bug · 執行直接用例，發現大部分的bug； · 帶隨機的大量測試，試圖撞出bug； 4）完備性分析，確保無漏驗 · FA/AS完備性確認，確認FS/AS中的所有點都已納入測試點，并確保已被覆蓋，包括應用場景； · 接口完備性確認，保證所有的接口時序都已覆蓋，包括正常時序及異常時序； · 覆蓋率確認，分析所有的代碼覆蓋率、功能覆蓋率，保證全部覆蓋； · 代碼分析，熟練掌握電路的實現邏輯，保證所有的電路corner都已覆蓋； 上述這幾個步驟是一個比較規范的流程，只要每個步驟都做好，基本就能做到無漏測、零漏驗。 6 驗證的后話 1）驗證的空間 作為驗證人員最希望的情況是：把所有的激勵空間都覆蓋到，這樣就絕對能保證無漏測、零漏驗。但實際情況是：芯片規模越來越大，其激勵空間近乎無限，同時EDA仿真的速度奇慢，根本無法實現全覆蓋，即使是FPGA、EMU等仿真加速器對此也是無能為力。 因此，合理劃分激勵等價類是相當重要的，但這也一直是驗證的難點所在，很多情況下根本就沒法分析清楚等價類。 2）CDV驗證 CDV就是覆蓋率驅動驗證的意思，就是寫一大堆覆蓋率（斷言覆蓋率、功能覆蓋率、代碼覆蓋率），只要這些覆蓋率全都達到的話則表示驗證已經完備。 這是我們的目標，其前提是分析清楚我們的測試點覆蓋空間，這個分析也是讓人頭痛的事，沒有誰敢拍著胸脯說這個測試點空間是完備的。 3）formal驗證 傳統的仿真都是動態驗證，由于其仿真效率低下無法遍歷所有空間，formal這種靜態的驗證手段則可以遍歷所有空間。不過在目前這個階段，formal還只能適用于百萬門級的模塊驗證，同時目前市面上的formal工具大多要么只對控制邏輯支持較好，要么只對算法邏輯支持較好，幾乎沒有一款formal工具能完美支持所有的電路邏輯。 4）環境自動化 在驗證過程中，搭建驗證環境是一個機械性的勞動，但有時候又比較耗費時間而且容易出錯，因此把驗證環境做成自動化工具，還是能提高不少驗證效率的。 5）全部使用直接用例 從驗證流程中可以看到，用例執行過程中大部分bug在直接用例過程中被發現，但還有一部分隱藏比較深的bug只有通過隨機激勵來發現。 這里存在一個問題，隨機測試是不可靠的，有很大的概率發現不了隱藏的bug，對此可以有兩種方法： 一是采用帶約束的隨機，這樣可以更好的達到邊界點，這同樣存在概率性問題； 二是所有的corner點全部用直接用例覆蓋，這些直接用例執行一次即可發現所有的bug，根本不需要進行長期的隨機測試，這要求我們能識別出所有的corner點； 方法二是我們追求的目標，全部用直接用例覆蓋，取代長期隨機測試，可惜愿望是美好的。 6）復用的東西都BB化 在芯片設計中經常回重用以前的模塊，這樣不僅加快進度，而且能降低出錯風險；但是對于驗證人員來說，復用并不一定是好事情，經常會出現這樣的事情：由于是復用之前的模塊，所以在驗證的時候會掉以輕心，結果埋下bug。如果把復用模塊當做全新模塊來驗證，這又要花費大量的時間，可能就會延后芯片的投片時間。 對于復用的模塊，驗證人員也可以把驗證的相關東西做成BB化，后續芯片復用該模塊時，也可以復用該驗證BB。 |
