为什么还要做gate-level simulation

我们一般不做

At best you do it, otherwise if  some error cause by  compiler or  RTL coding issue, maybe you will got some  circuit design problem.

一般不作啊。gate仿真不直观，可用来确认rtl仿真,但实际run不起来，可能是综合问题。

很多年了，基本没有做过。

前辈说是为了防止X-transfer,有谁了解吗?

检查异步逻辑，上电复位逻辑，等一些在LEC,RTL仿真中难以覆盖的问题

gate-level simulation? 是指什么仿真啊， PR后? synthesis后?

    啊，这个。所有信号在仿真中开始都是X，只有赋值之后才有值。
X可以被传递，比如
1&X = X
0|X = X
仿真中如果复位之后一段时间之内还有信号是X，说明初始化不好，电路的逻辑取决于电路某些元件的初始值
这样的话，流片之后可能不工作
一般来说这个问题不大，前仿消除了所有复位问题的设计，到了后端一般不会出现这种问题，除非是设计本身的编码风格不好，本来就有设计问题

异步逻辑，上电复位逻辑在LEC和RTL仿真中不能覆盖到吗?能否举例说明一下?
此外还有哪些是LEC，RTL仿真不能覆盖到而post-simulation可以覆盖到的?

毕竟数字timing计算只是一种近似，不是太精确的。而且对于power nosie以及cross talk等效应，STA 有时候还是达不到要求，就需要用spice level simulation 来仿真。
spice level simulation 的字面意义应该是晶体管模型级仿真，是一种仿真方式，而不是大家所讨论的仿真方法。 把code 写好一点，不管是上电，复位，异步，甚至cross talk 等效应，都可以在rtl level 观察到。而spice level 如果没有写好激励，照样run 不出来这些效应。
对于数字工程师，只有在你对于数字库的近似不再信任，或者说你的设计要求，水平都超越.lib/db/ccs 的时候，就可以考虑spice simulation（如果现在的你还对于.lib 充满敬畏，甚至都没敢打开看过，那么掠过我说的所有话，立即回去，cd syn.  vi ****.lib 看看 ：）。
补充一点，即使要跑一个1k cell 的digital desing，用spice level run的话，也得要一台强劲的server，跑很多个小时。

shall be some asynchronous circuit. Reset circuit is part of analog.

确切的说应该是后仿真，使用后端PR反馈的gate-level网标和由spef文件提取的sdf文件。
后仿真的主要作用就是检查异步路径工作是否正常，因为STA是无法检查到的。
后仿真也检查复位滤毛刺工作是否正常，电路是否出现异常X态信号，端口连接是否有误等。
后仿真的速度很慢，仿真结果波形文件很大，因此只是有针对性的跑几个前仿真无法覆盖的地方。

    嗯，不是很同意你的观点。因为你说提到的后仿真一般是在cell level 做，通过背注（back annotation，我随便翻译的）由PT或者其他timing analysis工具抽取出来的延时信息，用数字方法进行仿真（所谓数字方法，即信号中只有1，0，z，x，而不可能有0.4V，==）。其实质还是在cell level 进行仿真。和gate -level simulation 还是有很大差别。其实gate level simulation 也有pre-layout，就是你说的前仿和post layout simulation 之分。

看来这个已经上升到analog的层次了

有些内部模块复位做的不好，可能会出现X的情况，这些X一般的会传递到输出端口，但是有的时候可能是激励或者仿真环境，或者其他原因会导致前端功能仿真并不能发现这些问题，但是gate-level simulation会发现这些问题。

RTL仿真 和门级仿真 究竟区别在哪里咧?

保证网表与rtl的一致性

不错的资料，支持

被骗了，资料不好

正好经历相同的问题，在百度搜了半天搜不到，然后用谷歌就很快找到了，把原文铁贴出来，大家一起学习：
-----------------------------------------------------------------------------------------------------------------------
Introduction
Simulations are an important part of the verification cycle in the process of hardware designing. It can be performed at varying degrees of physical abstraction:
(a)    Transistor level
(b)    Gate level
(c)    Register transfer level (RTL)
In many companies RTL simulations is the basic requirement to signoff design cycle, but lately there is an increasing trend in the industry [1] to run gate level simulations (GLS) before going into the last stage of chip manufacturing. Improvements in static verification tools like Static timing analysis (STA) and Equivalence Checking (EC) have leveraged GLS to some extent but so far none of the tools have been able to completely remove it. GLS still remains a significant step of the verification cycle footprint. This paper focuses mainly on the steps to run GLS from verification perspective and the challenges faced while running it.
Firstly, let us look at the reasons why GLS is still used in the industry despite all the challenges associated with its execution.
Motivation for running gate level simulations
The main reasons for running GLS are as follows:
To verify the power up and reset operation of the design and also to check that the design does not have any unintentional dependencies on initial conditions.
To give confidence in verification of low power structures, absent in RTL and added during synthesis.
It is a probable method to catch multicycle paths if tests exercising them are available.
Power estimation is done on netlist for the power numbers.
To verify DFT structures absent in RTL and added during or after synthesis. Scan chains are generally inserted after the gate level netlist has been created. Hence, gate level simulations are often used to determine whether scan chains are correct. GLS is also required to simulate ATPG patterns.
Tester patterns (patterns to screen parts for functional or structural defects on tester) simulations are done on gate level netlist.
To help reveal glitches on edge sensitive signals due to combination logic. Using both worst and best-case timing may be necessary.
It is a probable method to check the critical timing paths of asynchronous designs that are skipped by STA.
To avoid simulation artifacts that can mask bugs at RTL level (because of no delays at RTL level).
Could give insight to constructs that can cause simulation-synthesis mismatch and can cause issues at the netlist level.
To check special logic circuits and design topology that may include feedback and/or initial state considerations, or circuit tricks. If a designer is concerned about some logic then this is good candidate for gate simulation. Typically, it is a good idea to check reset circuits in gate simulation. Also, to check if we have any uninitialized logic in the design which is not intended and can cause issues on silicon.
To check if design works at the desired frequency with actual delays in place.
It is a probable method to find out the need for synchronizers if absent in design. It will cause “x” propagation on timing violation on that flop.
Execution strategy for GLS
1. Planning the test-suite wisely to be run in GLS
In highly integrated products it is not possible to run gate simulation for all the SoC tests due to the simulation and debug time required .Therefore, the list of vectors which are to be run in GLS has be selected judiciously. The possible candidates for this list  are:
Testcases involving initialization, boot up.
All the blocks of the design must have atleast one testcase for GLS.
Testcases checking clock source switching.
Cases checking clock frequency scaling.
Asynchronous paths in the design.
Testcases which check entry/exit from different modes of the design.
Dedicated tests for timing exceptions in the STA.
Patterns covering multi clock domain paths in the design
Multi reset patterns are a good candidate for GLS
It must also be made sure that the test cases selected to be run in GLS are targeting the   maximum desired operating frequency of the design. Should there be no time constraints, all tests run in RTL simulations can be rerun in GLS. Also, if there are no tests fulfilling the criteria mentioned above, then they should be coded.
2. Preserving design signals
Some signals which are critical for GLS debug can be preserved while synthesis.
3. Testbench updates for GLS
A list of all the synchronizer flops is generated using CDC tools. Also, other known asynchronous paths where timing checks needs to be turned off are analyzed and complete list of such flops is prepared which also includes reset synchronizers. The timing checks are turned off on all such flops to avoid any redundant debugging, otherwise they will cause “x” corruption in GLS. This work should be ideally done before the SDF arrives .It may happen that the name of the synchronizers in RTL and the netlist are different. All such flops should be updated as per netlist .Also, the correct standard cell libraries, correct models of analog blocks, etc. need to be picked for GLS.
4. Initialization of non resettable flops in the design
One of the main challenges in GLS is the “x” propagation debug. X corruption may be caused by a number of reasons such as timing violations, uninitialized memory and non resettable flops . There are uninitialized flops in design which by architecture are guaranteed to not cause any problems (if they settle to any value at start). Thus, there is a need to find out all such flops in the design (which are reviewed with designers) and initialize them to some random value (either 0 or 1) so as to mimic silicon.
5. Unit delay GLS for testbench cleanup
This step is not compulsory but is generally very fruitful if employed in the GLS execution. The setup is done for unit delay GLS (no SDF) and the testcases that are planned to be run on gate level are run with this setup to clean the testbench. This is done because the unit delay simulations are relatively faster (than those with SDF) and all the testbench/testcase related issues can be resolved here (for example -  change probed logic hierarchy from rtl to gate, wrong flow of testcase, use of uninitialized variables in the testcases that can cause corruption when read via core, etc). Running the unit delay GLS is recommended because one can catch most of the testbench/testcase issues before the arrival of SDF. After the SDF arrives, focus should be more on finding the real design/timing issues, so we need to make sure that the time does not get wasted in debugging the testcase related issues at that time.
6. Annotation warnings cleanup on SDF
When the SDF is delivered to verification team, then the simulations are run with the SDF/netlist. Specific tool switches need to be passed which picks us the SDF and tries to annotate the delays mentioned in the SDF to the corresponding instances/arcs in the netlist. This is known as “back-annotation.”
During this process, many annotation warnings are encountered which need to be analyzed and either sorted out or waived off by the design team. Most important warnings which need to be looked into are the ones which are due to non-existent paths i.e. the SDF has an arc but netlist does not have it. Also, there can be mismatch between the simulation model “specify” block and .lib of the IP.
7. Running GLS with SDF:
     (a)  Early SDF (for initial debug)
This step involves use of a sdf in which timing is met at a  lower frequency than target and GLS can be run at that frequency. This helps in cleaning up the flow and finding certain issues before the final SDF arrives.
      (b) Full speed SDF (WCS and BCS)
This step starts with the sdf in which timing is met at target frequency. The entire setup is done and the planned pattern-suite is run on this setup and failures needs to be debugged according to a priority list which should be made before hand. All the high priority patterns need to be debugged first.
All issues found are discussed with the design and timing team and the required fixes are done in the netlist/SDF. This process is repeated until the GLS regression is clean on the final SDF.
The following diagram shows the GLS sign off flow:

Challenges faced during GLS setup
GLS with SDF delays annotated is usually very slow and time consuming. A lot of planning is needed to wisely select the patterns that need to be simulated on netlist. Run-time for these tests and memory requirements for dump and logs must also be considered. Identifying the optimal list of tests to efficiently utilize GLS in discovering functional or timing bugs is tough. These are to be decided with discussions with timing team and design team on which paths are timing critical/asynchronous and needs to be checked.
GLS is much more difficult than RTL simulations as delays of gates, interconnects comes into picture and RTL assumptions for arrival of data/clock may mismatch causing failures.
During the initial stages of GLS, identifying the list of flops/latches that needs to be initialized (forced reset) is a big hurdle. The pessimism in simulations would cause “x” on the output of all such components without proper reset, bringing GLS to a standstill. If approved by design and architecture team, these initializations should be done to move forward.
During synthesis, the port/nets may get optimized/re-named to meet the timing on these paths. Monitors/Assertions hooked in testbench during RTL simulations need to be revised for GLS to make sure the intended net is getting probed. Also, in netlist there can be inverters that can be inserted on that signal driver due to boundary optimization and can cause false failures (not having any design issues). This is really tough to figure out and debug.
If the gate level simulation with SDF is done without a complete synchronizer list , then failure  debug  to find such cases on gate level is quite cumbersome.  Multiple debug iterations may happen in GLS to find out many such flops.
Debugging the netlist simulations is a big challenge. In GLS, models of the cells make the output “x” if there is a timing violation on that cell. Identifying the right source of the problem requires probing the waveforms at length which means huge dump files or rerunning simulations multiple times to get the right timing window for violations. The latest tools are offering “x” tracing techniques for quickly tracing the source of “x” propagation. Such tool features need to be explored. All said and done, it can be concluded that one requires a lot of patience while debugging the GLS waveforms.
Conclusion
In short, despite being a time consuming activity and having many challenges in setup and debug, GLS is a great confidence booster in the quality of the design. It can uncover certain hidden issues which get missed out or difficult to find by RTL simulations. This is the reason many organizations prefer this activity before tape-out because it is more close to the actual silicon and gives a fairly good idea about how the design will behave in real. The probability of having sound sleep after tape out improves with GLS.
References
Goering, Richard, "Functional Verification Survey -- Why Gate-Level Simulation is Increasing," Cadence, January 16, 2013.
Goering, Richard, "Whitepaper Review: Improving Gate-Level Simulation Performance," Cadence, February 18, 2013.
Logic simulation, Wikipedia.
Jalan, Gaurav, "Gate Level Simulations : A Necessary Evil - Part 2," whatisverification.blogspot.in, June 29, 2011.
"Gate level simulation - Introduction," The Digital Electronics Blog, October 16, 2006.

因为有些logic被优化掉了，如果不继续仿真，则会导致netlist和RTL功能不一致！

稍微大些的gatelevel级仿真hspice是跑不起来的,一般用nanosim或hsim. 另外加上VCS进行co-sim更好.