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.
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.
- To check if reset release, initialization sequence and boot-up is proper.
- Since Scan insertions occur during and after synthesis, they are not checked by simulations.
- STA does not analyze asynchronous interfaces.
- 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.
- Usage of create_clock instead of using create_generated_clock between clock domains.
- For switching factor to estimate power.
- X's in RTL sim can be pessimistic or optimistic. Any unintended dependencies on initial conditions can be found through GLS.
- Design changes, wrong understanding of the design can lead to incorrect false paths or multicycle paths in the constraints.
- Can be used to study the activity factor for power estimation.
- It's an excellent feel good quotient that the design has been implemented correctly.