Gate level simulation is used to boost the confidence regarding implementation of a design and can help verify dynamic circuit behaviour, which cannot be verified accurately by static methods. It is a significant step in the verification process.
Gate level simulation overcomes the limitations of static-timing analysis and is increasing being used due to low power issues, complex timing checks at 40nm and below, design for test (DFT) insertion at gate level and low power considerations. For DFT, scan chains are inserted after the gate-level netlist is created; gate level simulation is often used to determine whether scan chains are correct.
Technology libraries at 45nm and below have far more timing checks and complex timing checks than older process nodes. Gate level simulation may take up to one-third of the simulation time and could potentially take most of the debugging time. It is run after RTL code is simulated and synthesized into a gate-level netlist. It requires a complete reset of the design.
Reasons for running gate level simulation are reset verification, X optimism in RTL, timing verification on multi-cycle/asynchronous paths and basic heartbeat test.
In reset verification, gate level simulation can verify system initialization and show that the reset sequence is correct.
In X optimism in RTL, an RTL simulator may optimistically assign zero or one to a value that a gate level simulation would identify as X (unknown).
In timing verification on multi-cycle/asynchronous paths, static-timing analysis cannot identify asynchronous interfaces, and has constraint requirements that impact false and multi-cycle paths.
In the basic heartbeat test, some verification teams may want to run a limited sanity check to verify the functionality at the gate level. As gate level simulation runs much more slowly than an RTL simulation, it potentially has significant impact on the verification closure cycle.
Cadence incisive enterprise simulator has several features such as zero-delay simulation, built-in delay mode control functions to reduce simulation time, selectively disabling delays in sections of the model where timing is not currently a concern, detecting potential zero-delay gate loops, correcting race conditions that occur in zero-delay mode, disabling timing checks for the entire simulation or for selected blocks, controlling the number of timing check violations, using multi-snapshot incremental elaboration to improve elaboration performance, using wave dumping only if required, avoid or use selectively command-line options that provide additional information and access to objects for debugging.
Incisive also offers a timing file that lets you turn off the timing for particular instances in a design. Palladium XP accelerator/emulator can offer speeds 10,000 times faster than simulation. If full debug access is needed, a switch can provide it. There is also an option (-ZLIB) that can compress snapshots and save disk space, while letting users set the level of compression.
Running a gate level simulation
The use of static tools to reduce gate level simulation time should be used before running zero-delay information, especially for linting. Static-timing analysis can provide information that is used to start gate level simulation early in the flow.
There are many reasons for running gate level simulation, some of which are given below:
1. To give confidence in verification of low-power structures, absent in RTL and added during synthesis. It is a probable method to catch multi-cycle paths if tests exercising these are available. Power estimation is done on the netlist for power numbers
2. To verify the power-up and reset operation of the design and to check if the design has any unintentional dependencies on initial conditions
3. 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 simulation is often used to determine whether scan chains are correct. It is also required to simulate ATPG patterns. Tester pattern simulations are done on the gate-level netlist
4. To help reveal glitches on edge-sensitive signals due to combination logic; using both worst- and best-case timing may be necessary
5. To check special logic circuits and design topology that may include feedback and/or initial state considerations or circuit tricks
6. 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 synchronisers, if absent in design. It will cause X propagation on timing violation on that flop
Gate level simulation execution strategy
In highly integrated products, it is not possible to run gate simulation for all system on chip (SoC) tests due to the simulation and debug time required. Therefore the vectors that are to be run in gate level simulation have to be selected judiciously.
Possible candidates for such vectors are test cases involving initialisation and boot up, and all blocks of the design must have at least one test case for gate level simulation, test cases checking clock source switching, cases checking clock frequency scaling, asynchronous paths in design, test cases that check entry/exit from different modes of design and dedicated tests for timing exceptions in the STA.