最近又跟別人一起debug後仿的幺蛾子，簡單梳理一遍，供日後索引。
我們跑功能後仿的目的主要有以下幾種：
1. 驗證網表功能的正確性。
2. 驗證STA收斂後網表的時序正確性。
3. 功耗分析；
4. IRDROP分析；
我們最早可以在芯片綜合出第一版網表、formal verification pass之後，就開始第一輪後仿的調試。
這時的後仿使用DC之後ICC之前的網表，不具備clock tree信息，更別提反標時序信息了。所以這時的後仿僅用於調通芯片的後仿flow、初步驗證網表功能的正確性、以及非常粗略的各IP模塊功耗預估（因爲沒有clock tree信息，這時clock上的功耗會偏低很多）。
這一輪需要在vcs仿真的編譯選項中加入+notimingcheck，使用的stdcell.v文件頭加+functional+聲明，從而關閉stdcell中的delay，全部用0延時。
（以前也有一些foundary提供的庫文件，我們會手動加上一個非常小的0.001ns的delay）
如果RTL設計中存在不受復位控制的同步邏輯，還需要用DC或PT從網表中抽取所有寄存器類型和列表，對寄存器Q/QN/QB端做”force -deposite xxx.Q 初值“操作，防止不受復位控制導致的X態傳遞。使用到SRAM的邏輯，如果代碼風格好，不太需要對SRAM Q端做操作。如果代碼風格不太好，那麼穩妥起見，SRAM的Q/QA/QB也給force一下初值會比較安全。
如果同步邏輯佔比例較多，那麼最好force 0/force 1/force random值的case都跑一下，對功能覆蓋的更全面。有些代碼風格不太好的邏輯，會因爲隨機初值導致意料之外的錯誤發生。這種靠前仿是查不出來的（前仿加隨機的initreg0/1/x/z也許可以），除了後仿就只能靠代碼review/強制統一代碼風格來保證了。
加force需要在vcs編譯選項中加-debug_all, -P celllist.tab, 要在simv後面加-ucli -do force.do, force.do中執行source force.ucli和run兩行tcl命令。
當然vcs編譯選項中也有自帶的initreg和initmem選項，不過這倆對於網表是否還會起作用呢？這個我還沒有試過哈：）
綜合出來的網表給到後端、後端跑完第一輪之後，返回網表和starrc提取出的各corner spef文件，有這些作爲輸入，就可以開始第二輪後仿調試了。
這時的後仿已經有完整clock tree信息以及反標時序信息，但STA未必收斂，可能還帶着很多violation。所以這時的後仿也僅用於調通芯片反標後仿flow、驗證反標信息的正確性，並且可以大致看一下clock tree上的功耗。
在pt中讀入icc輸出網表和starrc輸出spef文件，通過"write_sdf"命令寫出各corner對應的*.sdf文件。該文件作爲驗證的輸入。
編譯的選項摘抄了一下（http://blog.sina.com.cn/s/blog_bc93ac450102x0gh.html）：
這一輪因爲反標延時的violation大概率還有很多，所以VCS中依然打開+notimingcheck。同時需要添加+neg_tchk -negdelay等選項。
針對功耗分析，驗證至少會構造2個定向測試用例，一個最大功耗模式，一個最小功耗模式。把後仿產生的fsdb文件轉成vcd。vcd作爲pt的輸入，可以得到芯片在各corner下的功耗數據。
用最大功耗模式下的vcd作爲Redhawk的輸入，可以得到芯片的IRDROP分析數據。
STA clean後，會跑最後一輪後仿，進行最終的功能check、反標時序check、得到最終的功耗和IRDROP數據。