數字集成電路(IC)開發流程介紹

數字集成電路(IC)的整個開發流程是很復雜的，下圖以一個數字IP在整個IC開發過程中要經過的環節為例來做個簡單的介紹。希望對大家的理解有所幫助并理解不同職位的工程師的職責所在。雖然目前業界主要有3家EDA tool提供商（Synopsys, Cadence, Mentor), 但因為作者本人對Synopsys公司的工具比較熟悉，所以涉及到的EDA工具會主要以Synopsys公司的為主。受限于篇幅，很多環節只會提到其中的主要目的。

整個流程可以分成3個大的階段：

RTL開發階段 (前端工程師職責所在)

layout前的開發階段 (一般也由前端工程師負責)

layout后的開發階段 (后端工程師的職責)

大家可以看看下圖對這3個階段有個直觀的認知：

1. 先來講講RTL開發階段：

第一步是制定IP的SPEC, 這個階段可能會要參考一些業界的標準，例如Ethernet MAC IP的開發一定會要去參考IEEE 802.3 standard。有時候基于客戶或系統層面的應用需求，可能還會加入一些定制化的需求在里面。這就需要SPEC制定者與marketing, customer, system architecturer, SoC bus designer等等與當前IP相關的人員充分討論，而不是單純的閉門造車。

SPEC制定后，設計工程師會開始做 RTL design。設計工程師一般用Verilog來實現RTL design, 也有用VHDL的，但就作者所接觸的公司來看不是主流。近年來也有些公司在嘗試用System Verilog來做RTL design, 其效果和EDA tool對其支持的完善程度還有待驗證。

RTL coding完后，一般都由負責設計此RTL的設計工程師繼續做一些RTL品質的檢查，例如RTL代碼風格檢查，跨時鐘域的檢查等。這些檢查目前主流的工具有Synopsys公司的 Spyglass. 為什么要做這些檢查呢? 根本目的就是保證RTL設計的代碼是可以被EDA工具綜合（暫時理解為“翻譯”）成物理電路世界的具體電路（例如AND/OR/NAND gate, Dflipflop等)，并且這些電路的功能是吻合設計者的預期的。舉個最簡單的例子，有些Verilog語法本身是無法被EDA tool翻譯成具體的電路的，例如Integer類型的變量。

在設計工程師做上述事情的同時，驗證工程師會同步開始他的驗證工作。首先是根據自己對SPEC的理解編寫驗證規劃。這個過程中遇到理解上的問題可以找SPEC制定者和設計工程師討論，但是有個原則是不能什么都聽他們的，你覺得有道理的可以采納，你覺得沒有道理的就要勇于和他們充分討論。某些bug可能在前期的討論中就會被發現。

驗證規劃里面要包含整個驗證環境的框架和主要組成部分的介紹。還有SPEC中提到的所有的功能點也要列出來（最簡單的就是用excel file）,并說明怎么去測試這些功能點。

驗證規劃制定好后，要找SPEC制定者和設計工程師審核（review），確保沒有理解上的偏差和驗證漏洞。這個過程可能會有幾個來回，對你的細心和耐心也是一種考驗。

驗證規劃審核通過后，就可以開始搭建具體的驗證環境，搭建方法一種是用Verilog語言來搭建，另一種是用UVM來搭建。前者相對簡單些，驗證者可以在較短的時間里就搭建好一個基本的環境。后者相對復雜，但搭建好后，能夠更快地實現所有的測試項目。具體的差別我們可以在另一篇文章中來具體介紹。不管用什么方法都涉及到編譯和仿真工具的選擇。例如Synopsys公司的VCS或cadence的IRUN。

驗證環境寫好后，驗證工程師就可以開始用它來測試設計工程師交付的RTL。絕大部分的設計缺陷都是在這個階段的動態仿真中發現的。這期間除了分析打印在電腦屏幕上或log file中的debug信息(由建立驗證環境和測試用例時由驗證工程師所寫的$display等打印函數打印出來的)，你可能需要用到synopsys的Verdi來分析波形圖以確定到底是RTL的設計缺陷還是驗證環境的設計缺陷。

設計工程師的設計成果可以由驗證工程師來把關，那驗證工程師的工作成果的品質如何保證呢？一方面是靠相關工程師的人工審核（review），另一方面是靠代碼覆蓋率（code coverage）和功能覆蓋率(function coverage)的客觀結果。代碼覆蓋率就是RTL設計中的每一行代碼，甚至每一個變量的變化都有被驗證環境覆蓋到。這個不論你的驗證環境是Verilog寫的還是UVM寫的，都會被衡量。功能覆蓋率是System Verilog 語言才有的一種方法，驗證工程師通過它來保證所有從SPEC中抽取出的功能點都有被UVM環境覆蓋到。具體的解釋，將在別的文章中展開。

2. 設計工程師在完RTL設計和品質檢查后，除了和驗證工程師一起確認和修正RTL設計缺陷外，就可以開始進入下一個大的階段：即第一張圖中的pre-layout gate-level netlist階段 （layout前的開發階段）。

第一步是用EDA工具將RTL設計的代碼翻譯成物理電路世界的具體電路（例如AND/OR/NAND gate, Dflipflop等)，這個步驟專業的稱呼叫”綜合“。這個階段可以使用的EDA工具有Synopsys的Design Compiler或cadence的RTL Compiler。

靜態時序分析（Static Timing Analysis, STA）：STA是一種分析電路是否滿足時序需求的一種方法。所謂的“靜態”就體現在它不需要進行動態仿真。數字電路的基本組成簡言之可以看成組合邏輯門（例如AND/OR gate）和時序邏輯（例如DFF）的組合. 如下圖所示（圓圈表示組合邏輯電路）。組合邏輯電路的復雜度，就決定了電路能否在給定頻率的clk下正常工作。相關的工具有Synopsys的PrimeTime.

Design for Test (DFT)：在芯片的制造和封裝過程中，可能會出現一些瑕疵。DFT 的目的就是將一些特殊結構（例如scan chain）在設計階段植入原始電路中，以便芯片制造出來后可以對它進行測試看看哪些芯片是好的可以賣給客戶，哪些是有問題需要丟棄的。想想看一個幾千萬門或上億門的IC在生產出來后，芯片內部任一個門有問題，都需要能夠通過DFT電路觀察出來，是不是有點神奇？相關的工具有Synopsys的DFT compiler和tetramax。

Power Analysis：分析所設計的電路需要消耗多少能量。想想手機電池基本要一日一充的痛苦，芯片設計工程師也正在想盡一切辦法讓自己的電路能夠盡可能的少消耗一些能量來提升用戶體驗。power分為靜態power和動態power, 靜態power主要指漏電引起的power消耗，例如CMOS的source到drain的亞閾值電流引起的power消耗。動態power又分為2類，一類是switching power, 是指電路狀態翻轉引起的對cell外部負載電容充放電引起的power消耗，另一類是internal power,是指對cell內部負載電容充放電引起的power消耗和短路電流引起的power消耗。tool要想算出準確的power的消耗，在指定制程的前提下，還需要知道每個cell的每個pin的翻轉頻率，transition time和cell的電容負載值。翻轉頻率可以通過simulation得到，準確的transition time和電容負載值需要在layout之后抽出實際的RC值才能得到，這就是為什么第一張流程圖中在post-layout階段還有一次power的分析步驟。相關的工具有Synopsys的PrimeTime

Gate level Simulation(GLS)： 將綜合得到的gate level netlist 拿來再做一次動態仿真測試。這個仿真應該盡可能的考慮到實際物理電路的timing信息，這個信息可以由layout工程師在完成layout后提供給你。在layout完成前做GLS的話，就只能依靠 cell library中提供的WLM來估計實際物理電路中的 delay信息了。因為仿真對象已經從RTL 變成了gate, 因此仿真工具需要讀取一個描述每種gate行為和delay信息來源的仿真模型，這個simulation model會由cell library 的提供商提供。既然前面已經做了RTL sim 和 STA，為什么還需要GLS呢？主要原因有以下幾點：

coding style問題可能導致綜合前后Function會不一致，例如多個always block對同一個信號做了賦值，RTL simulation中的電路行為和實際門級電路的行為可能會不一致。

STA是基于人寫的constraint,可能會有漏洞，也可能會有筆誤。

異步電路（例如跨時鐘域的電路）在STA中是無法被分析的。

各家EDA公司的RTL仿真工具都可以被用來做GLS，只是流程上要注意仿真對象發生了改變，以及綜合或layout后得到的實際電路的timing 信息如何反標到gate level netlist中，相關仿真工具的user guide會有詳細說明。

Formal verification：因為coding style問題可能導致綜合前后Function會不一致，我們可以用Gate-level Simulation 得知合成后Function之正確性，但假使驗證后發現Function 不正確，要用Debug Tool 來抓錯誤點，往往需要耗上相當多的時間，為解決這問題，可以使用Formal Verification 工具找出其問題點. 設計者須準備綜合前的Golden RTL Code 與綜合后產生的Gate-level Netlist (Revised Code)及其相關Library檔，在添加一些合理的約束信息后（例如，當綜合時有額外添加電路如TestingCircuit，可以給定Constraints 予以Mask掉），工具就可以將整個電路切割成一個個的logic cone, logic cone的輸入和輸出往往是I/O或DFF，然后工具會給這些Logic cone提供各種可能的輸入值，如果logic cone的輸出結果在2個版本的設計中永遠都是一致的，那么就表示PASS。相關的工具有Synopsys的Formality和Cadence的LEC.

FPGA測試：這個環節很多國內的研究生是比較熟悉的。因為FPGA板子上的測試可以看到的設計內部的信號是有限的， 所以FPGA測試時遇到問題的debug難度是遠大于RTL動態仿真時的debug的。并且既然RTL動態仿真已經將所有可能的功能點都cover了，為什么還需要做FPGA測試呢？根據作者的認知主要有如下幾點考量：

FPGA上的測試可以真實的驗證軟件和硬件的協作流程

可以和真實的關聯設備協同驗證，例如USB host controller和市面上的各種U盤一起驗證，可以保證所設計的USB host controller的兼容性。

一些需要和模擬電路協同工作的IP在RTL仿真時往往是使用的模擬電路的行為級模型，這個模型可能存在和實際電路行為不一致之處。在FPGA測試時可以使用模擬電路的實際電路（一般會先開發出相關的test chip并做成子板）來確保不會有問題。

常見的工具有Synplify和ISE.

3. 接下來我們講講 gate level post-layout 這個階段的工作任務: 這個階段的主線任務簡單說就是將上一階段產出的 gate level netlist 經過布局布線，生成 GDSII文件，然后就可以把這個GDSII文件提交給芯片制造代工廠生產出最終的芯片。 具體的工作內容說明如下：

Placement & Route:

在Placement步驟中，APR軟件 (例如Synopsys 的 ICC 或者 Cadence 的Encounter) 會根據設計者的Constraint將Cell擺放至適當方位以滿足規格，假使未滿足規格，設計者可再透過Placement Optimization取得更好的Performance。另外假使有Testing Circuit，需要在Placement時將Scan Chain作Re-order(因為在place & route 之前，syntest產生netlist中scanchain時因為無法知道各個寄存器物理位置的信息，會造成P&R后， chain上一個寄存器連接到很遠的另一個寄存器的情況，布線不優化（chain所用到的總線長很長）甚至造成擁擠。因此會在布局布線后重新reorder scan chain. 但是要注意reorder后hold timing 會變差。reorder scan chain 是根據這些register的物理位置來改變scan chain 中register的順序（connectivity）)，以取得較好的Performance。完成Placement后即可開始進行Clock Tree Synthesis(CTS)，目的讓每個Clock Signal可以balance送至Flip-Flop的末端，以降低Clock Skew及增加Clock Signal的推動力。最后再將Standard Cell、IO Pad Cell、Macro等Cell之Signal Pin進行繞線，并作Routing Optimization達成規格，完成Routing步驟。完成整個芯片P&R后，確認都沒Violation后即可存成Post-layout GDSII及Gate-level Netlist檔案

從整個APR Flow 可以發現，Placement、CTS、Routing 這些都是軟件在作的，這對設計者來說并非是難事，但是在Floorplan 及Power 的規劃卻是要花最多Effort 的，這是因為Design 中如果有多個Macro 時會不知道怎么擺放才可以做到滿足Timing 規格，也不知道要如何作出一個好的Power Mesh 規劃，像是P/G Cell 個數要多少？、Metal寬度要多少？Stripe 要幾條？才不會造成IR Drop 過多或Electro-Migration(EM)問題發生。這些問題常常困擾著設計者，也是Layout 最花時間的部分

EM問題：在電流密度很高的導體上，電子的流動會產生不小的動量，這種動量作用在金屬原子上時，就可能使一些金屬原子脫離金屬表面到處流竄，結果就會導致原本光滑的金屬導線的表面變得凹凸不平，造成永久性的損害。這種損害是個逐漸積累的過程，當這種“凹凸不平”多到一定程度的時候，就會造成CPU內部導線的斷路與短路，而最終使得CPU報廢。溫度越高，電子流動所產生的作用就越大，其徹底破壞CPU內一條通路的時間就越少，即CPU的壽命也就越短，這也就是高溫會縮短CPU壽命的本質原因

Post-layout power analysis：Layout 過程中，當完成Power Mesh 規劃及Cell、Macro 擺定位后，為了確認目前規劃的Power Mesh 夠Robust，不會造成IR Drop 超過合理范圍(一般為工作電壓10%以下)及EM Violations 發生，因此要使用Layout 軟件之Power Analysis 的功能進行分析。Power Analysis 前須準備包括，P/G Cell 個數及方位、該芯片的Input端的Transition Time(因一個Cell Power Consumption 是根據Input Transition 與Output Capacitance 查表得知的 )、Net Switch Activity。前面兩項可依實際電路給定，Switch Activity 須將目前Layout 結果存成Gate-level Netlist 并灌入實際的Pattern 進行Simulation得到。

Formal verification：Layout 后，電路的Function 有可能因Layout 而有所改變。會造成電路Function 錯誤原因一般是Signal Pin 被floating 掉或CTS 出了問題(這與synthesis后function改變原因不一樣)。因此在Layout 后還要再作Gate-level Post-layout Simulation 以確認Function是否正確。但假使驗證后發現Function 不正確，要用Debug Tool來抓錯誤點，往往需要耗上相當多的時間，為解決這問題，同樣地我們可以使用Formal Verification工具幫忙找出其問題點（但是對于CTS造成timing不對而影響function還是只能通過simulation才能找到問題）

Gate level simulation：在Layout時，設計者要提供RC Table 給Tool 計算Net 的Delay，RC Table 都是由Library 廠商會提供，該Table 可以查到每unit 長度的Metal 其RC 值為多少，Tool 會自動查表并計算Net 長度為多少，來決定每條Net 的Delay 是多少。由于Layout 時已有實際電路存在，Tool 可以依據實際長度計算出Net Delay 時間，因此跟綜合時所使用的WLM 準確度差異甚多。因此每次設計者要Report Timing 前，都要針對目前Layout 電路再作一次RC Extraction，以取得精確地Delay Calculation，直到最后Layout 完成產生正確的sdf 檔，作為Post-layout Gate-level Simulation之用。

Design Rule Check(DRC)：將Layout 結果，依據Foundry 對該制程定義的Max or Min Width、最小圖像間距，金屬寬度等Rule 作確認有無違反,若不check則代工廠生產出來的可能是廢品。

Layout vs. Schematic (LVS)：將Layout 結果（GDS）與Schematic(netlist)作比對，比較兩者間Instance、Port(PIN)、Net 等個數、Cell 連線情況及Power/Ground連接是否一致，以確認Layout 完結果之正確性

壹芯微科技針對二三極管,MOS管作出了良好的性能測試，應用各大領域，如果您有遇到什么需要幫助解決的,可以點擊右邊的工程師,或者點擊銷售經理給您精準的報價以及產品介紹