1. 程式人生 > >晶片驗證全視之一:功能驗證介紹

晶片驗證全視之一:功能驗證介紹

如果你在設計一款計算器,除了加減乘除的基本功能以外,在科學計算層面上,你需要注意到三角函式、取模、階乘、冪運算、開根號等等複雜運算。

如果你在設計一款處理器,你需要考慮將其拆分成為運算器(算術邏輯運算單元,ALU,Arithmetic Logic Unit)和高速緩衝儲存器(Cache)及實現它們之間聯絡的資料(Data)、控制及狀態的匯流排(Bus)。

如果你在設計一款系統整合晶片(SoC, System-on-Chip),那麼它可能包括的子系統包括有處理器,片上網路(NoC, Network-on-Chip),儲存器,I/O控制器(多種類,例如USB,PCIe,I2C, I2S)等等。

你會發現,隨著系統整合度的提高,系統自身的複雜性也在隨之增加,而且結合實際工程專案來看,系統複雜度的提高對於功能驗證的要求是首當其衝的。由於功能驗證在晶片全流程中佔據關鍵位置,對於一名驗證工程師而言,他需要充分理解系統驗證的全過程,這個過程就是功能驗證的生命週期

。功能驗證在專案的延續中(目前的晶片之所以迭代週期越來越短,就是採取剪裁以前專案來做快速的晶片設計流程),可以得到不斷的提升;同時功能驗證處於所在專案中時,也需要考慮如何完善驗證流程和環境。

那麼我們本文將帶大家從晶片完整開發流程進入,來檢視晶片驗證在整個專案中的地位和作用。

一般來講,新的晶片專案都是首先從市場人員與目標客戶溝通開始的。這中間,市場人員會收集客戶對於晶片的要求(主要包括功能、尺寸、功耗、效能),這些指標會被記錄在設計結構和產品文件中去。隨後,客戶關心的系統層面的功能要求會被系統設計人員按照功能進一步劃分為各個獨立的子系統模組,這些子系統如果本身過於龐大,也會被進一步劃分為功能模組,直到被劃分的尺寸可以被小的設計團隊進行硬體設計。

在這中間,如果硬體設計人員一般會按照晶片的功能模組劃分來分成不同的功能小組,同時系統設計人員的數目也會隨著系統複雜程度的升高而增加。在硬體設計過程中,硬體設計工程師會將具體的功能描述文字通過邏輯翻譯成為硬體描述語言(HDL,Hardware Description Language),目前使用廣泛的HDL語言VHDL和Verilog均被各個大的EDA(Electornic Design Automation)公司支援。同時,由於SystemVerilog語言本身具有Verilog的語言屬性和在此之上新增的硬體設計語言的額外屬性,SystemVerilog的部分子集也被歸納到了可以用來綜合的硬體設計語言當中。

當細分的合適大小模組初步完成RTL級(暫存器級別,Register Transfer Level)的硬體描述語言檔案之後,功能驗證人員會在這個時候做幾項工作來檢查硬體設計:

  1. HDL硬體描述檔案是否正確按照功能描述文件去實施了?

  2. 硬體設計人員是否有遺漏掉的額外情況(corner case)?

  3. 硬體設計是否足夠穩定來處理一些錯誤的情況(error response)?

實際專案中,硬體設計人員和功能驗證人員的合作是緊密的,這具體表現在了:

  1. 當系統設計團隊將功能需求翻譯為功能描述以後,硬體設計團隊和功能驗證團隊需要圍繞著功能描述文件分別展開硬體設計和功能驗證工作。

  2. 硬體設計團隊在初步翻譯出硬體描述檔案以後,功能驗證團隊需要將硬體描述檔案搭建驗證環境展開各個功能點的驗證。

  3. 當驗證環境測試出實際結果與預期結果不符合的情況下可以分為

    1. 如果硬體設計與功能描述文件存在明顯不符時,功能驗證人員會報告出存在的設計缺陷,同時硬體設計人員會修復硬體描述檔案,這樣從驗證到設計再轉回到驗證即完成一個缺陷檢測和修正週期。

    2. 當實際結果和預期結果有模糊的邊界時(例如時序問題,狀態機跳轉問題),驗證人員和設計人員會就同一份功能描述檔案的理解存在分歧,此時他們會做初步的討論,來確定哪一方的理解有偏差。當討論依舊無法判定理解分歧的時候,雙方最終會找到系統設計人員進行“裁決”,來明確本來的系統設計思想,進而統一雙方對功能描述的理解。

因此,硬體設計的完成度和缺陷率會在設計人員和驗證人員的迭代週期中不斷得到完善,最終達到目標。關於功能驗證目標的定義,我們會在以後的文章“驗證的任務和目標”詳細講述。

當功能驗證完成以後,後端人員會將RTL檔案綜合生成門級網表文件(gate netlist),同時也會為了目標速度來進行佈局佈線,最終可以使得門級電路可以在設定的時鐘頻率上面工作。在後端的各種流程當中,與前端驗證人員聯絡緊密的當屬標準延時格式(SDF,Standard Delay Format)檔案,該檔案會包含門級網表中各個門單元之間的延時情況用來準確描述實際電路。

所以,對於功能驗證流程而言,我們所說的模擬可以根據專案的實施流程將其劃分為前端模擬和後端模擬:

  1. 前端模擬指的是進行RTL模擬,在這種模擬當中是沒有真實延時情況的。對於一個暫存器(register),它的輸出端(Q port)相對它的時鐘輸入端(Clk port)的延時為零延時(delta delay)。

  2. 後端模擬指的是進行Gate模擬。在實際專案中,由於後端綜合進而產生SDF檔案本身需要不斷迭代週期,我們進一步又將門級模擬劃分為零延時模擬和SDF模擬。

    1. 零延時模擬是隻有門級網表參與模擬,沒有SDF檔案來具體反向標註(back annotation)門級延時情況,所以門之間的延時仍然為零延時,這個時候門級零延時模擬與RTL模擬的區別僅在於前者是後者的邏輯對映,從暫存器級別到門級的邏輯轉譯,這一步是由後端的綜合工具(synthesis tooling)完成的。

    2. 當後端隨後產生出SDF檔案時,我們會將門級網表反向標註上SDF檔案中包含的每一條門單元之間路徑的延時,最終進行有真正延時電路的模擬。

從驗證完整性而言,前端模擬和後端模擬均需要在專案中實施,而它們側重的目標也有不同。前端模擬是為了檢測出功能邏輯的缺陷,而後端模擬是為了檢測出實際門級電路中由於延時問題可能導致取樣失敗進而產生的功能缺陷。也因此驗證人員不能將前端模擬的功能缺陷檢測任務下移到後端模擬階段,因為就效率問題而言,前端模擬要顯著高於後端模擬;同時,後端模擬之所以不能忽略是因為它可以協助後端人員來測試出實際生成電路中是否有時序不滿足的問題。

當完成後端模擬以後,我們會將後端生成的標準格式檔案最終交付給晶片生產商進行流片(tape out)。從上面的描述來看,這是一個完整的晶片從定義、分塊、設計、驗證和後端的矽前(pre-silicon)流程,同時晶片在流片以後所面臨的矽後流程(post-silicon)也是一個完整的週期,這其中包括了元件測試,驅動,系統韌體和應用軟體編寫等等。由於功能驗證處在矽前流程當中,我們在這裡主要闡述該流程,同時,我們也將一些相對獨立的部分略去(這並不代表它們不重要),例如可測試性設計(DFT,Design for Test)。

至此,晶片的矽前流程就結束了。考慮到驗證人員同設計人員在實際工作中的密切結合,我們舉出一個生活中的例子來情景演繹出設計驗證流程是如何進行的。

我女兒濛濛三歲了,小姑娘喜歡吃糖,她媽媽每次碰到她索要糖果也是沒有什麼好辦法。這個時候,她的工程師爸爸給出了一個流程圖來應對濛濛要吃糖的情況。

這張圖畫了出來給蒙媽看了一下,蒙媽看過以後笑著講,你先試試看你這一套有沒有用吧。

等到小傢伙過了一會兒又來要糖的時候,我問她,你是不是之前剛吃過啊?濛濛點了點頭,說是。我接著問,可是還需要等4個小時才可以吃下一顆啊。濛濛這時候不懂4個小時是多久,只是她一聽到“小時”兩個字就大約知道應該會挺久的,要知道她可等不了那麼久。於是乎,不屬於下面這個決策流程中的一幕發生了,小傢伙一開始央求我,後來覺著不靈就索性哭了。好吧,工程師爸爸的流程設計存在缺陷,於是,就把濛濛攬到懷裡,給她講了一個故事。濛濛聽完故事,滿意地又去別的地方玩兒了,彷彿忘了剛才還在因為一顆糖哭得一把眼淚。看到這招管用,於是我就把這個流程圖該成後來的樣子,經過親身經歷,又交給蒙媽看了看,這次蒙媽點了點頭,笑著說,知道孩子不好帶了吧……

是啊,即使作為一名有經驗的設計人員(Rocker),在面對新問題的時候(濛濛要吃糖),也不能對自己的設計太過自信,只有經過驗證人員(濛濛)充分驗證的設計才是經得起時間考驗的。說到這裡,看著我才修改的這張流程圖,我還是自信不起來,因為曉得講故事的套路說不定哪天就不管用了。如果到了那個時候,新的設計缺陷一旦暴露出來,那設計人員還是得再進一步完善設計,確保它的功能良好啊。

所以講,我和濛濛也是緊密協作的,就同設計人員和驗證人員一樣,當設計發生了問題,我不能生氣,不能太過自信,我需要坐下來同濛濛交談,找出缺陷在什麼地方,再將缺陷補上,下一次再交給濛濛,直到濛濛最終可以不用哭也能開心地吃到糖,同時我也不會因為她頻繁吃糖而擔心她的牙齒會壞掉。所以從這個角度來看,設計人員和驗證人員能夠在一起,是上輩子就修來的福分啊,不就像我跟濛濛一樣嗎?