Gate Level Simulation

Even though a lot of STA and Formal verification tools exists in the industry now a days, one question still arises in the mind of many verification engineers. The question is "Why do we go for a gate level simulation?"

Some years ago, I felt that gate level simulation were not worth. In my view, if we do static timing analysis (STA) - Those who want to know more about STA, please click  here  - after post and route, and take the post routed net-list, Extracted Parasitics File and design timing constraints, then perform design timing checks at all corners - say setup, hold and clock gating check - then we should be OK, no need to perform the gate level simulation. Then I realized if our chip has system clocks that only talk to others in synchronous, works in a single mode of operation and the STA setup includes no constants and false paths, then we can cover everything through STA tools.

Gate level simulation represents a small slice of what should actually be tested for a tape-out. They offer a warm feeling that, what you are going to get back will actually work and secondly, they offer some confidence that your static timing constraints are correct.

But the common reason to go for a gate level simulations are as follows:

• To check if the reset release, initialization sequence and boot up sequences are proper.
• STA tools doesn't verify the asynchronous interfaces.
• Unintended dependencies on initial conditions can be found through GLS
• Good for verifying the functionality and timing of circuits and paths that are not covered by STA tools
• Design changes can lead to incorrect false path/multi cycle path in the design constraints.
• It gives an excellent feeling that the design is implemented correctly

So before shipping a design to tape-out, we run a limited set of gate level simulations. Because there are some difficulties associated with this GLS, they are:

• Takes a lot of setting up and debugging
• Takes a huge amount of computing recourses ( CPU time and disk space for storing wave)
• RTL simulations alone take multiple days of run time even for a single regression. GLS takes 10* times.
• Generation of debug data (VCD, Debussy) is impossible with GLS

Some design teams use GLS only in a zero-delay, ideal clock mode to check that the design can come out of reset cleanly or that the test structures have been inserted properly. Other teams do fully back annotated simulation as a way to check that the static timing constraints have been set up correctly.

In all cases, getting a gate level simulation up and running is generally accompanied by a series of challenges so frustrating that they precipitate a shower of adjectives as caustic as those typically directed at your most unreliable internet service provider. There are many sources of trouble in gate level simulation. This series will look at examples of problems that can come from your library vendor, problems that come from the design, and problems that can come from synthesis. It will also look at some of the additional challenges that arise when running gate level simulation with back annotated SDF.

So In my opinion, the gate-level simulations are needed mainly to verify any environment and initialization issues.

Gate level simulation is used in the late design cycle to increase the level of confidence about a design implementation and can help to verify dynamic circuit behavior that cannot be accurately verified with static methods. For example the start up and reset phase of a chip. To reduce the overall cycle time, only a minimum amount of vectors should be simulated using the most accurate timing model available. 

Unit delay simulation

The net list after synthesis, but before routing does not contain the clock tree. It does not make sense to use SDF back annotation at this step, but GLS may be used to verify the reset circuit, the scan chain or to get data for power estimation. If no back annotation is used, simulators should use libraries which have the specified block containing timing arcs disabled and using Distributed delays instead. 

Full timing simulation with SDF

Simulation is run by taking full timing delays from SDF. The SDF file is used to back annotate values for propagation delays and timing checks to the Verilog gate level net list.

================================================================================

The common reasons quoted by many engineers are simple..

1. To check if reset release, initialization sequence and boot-up is proper.
2. Since Scan insertions occur during and after synthesis, they are not checked by simulations.
3. STA does not analyze asynchronous interfaces.
4. Unwarranted usage of wild cards in static timing constraints set false and multi cycle paths where they dont belong. This can also be due to design changes, mis-understanding or typos.
5. Usage of create_clock instead of using create_generated_clock between clock domains.
6. For switching factor to estimate power.
7. X's in RTL sim can be pessimistic or optimistic. Any unintended dependencies on initial conditions can be found through GLS.
8. Design changes, wrong understanding of the design can lead to incorrect false paths or multicycle paths in the constraints.
9. Can be used to study the activity factor for power estimation.
10. It's an excellent feel good quotient that the design has been implemented correctly.