Gate level simulation - Introduction

Gate level simulation (GLS) is a technique for verifying the functionality and timing of a digital circuit after it has been synthesized from a high-level description. It is an essential step in the design flow of integrated circuits, as it allows the designer to check for errors and optimize the performance of the circuit before fabrication. Gate level simulation is needed to verify the correctness of a digital design at the gate-level, which is the lowest level of abstraction in the design process. At this level, the design is implemented using logic gates such as AND, OR, and NOT gates, and flip-flops. 

With wide acceptance of STA and Formal verification tools by the industry, one question still pops up in the minds of many, "Why do we need gate-level simulation?"

The common reasons quoted by many engineers are the following:

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. This is used to validate the constraints used in STA and LEC. Static verification tools are constraint-based and they are only as good as the constraint used. Unchecked use of wildcards and late design changes not propagating to constraints or incorrect understanding of the design require validation of these constraints.
4. Unwarranted usage of wild cards in static timing constraints set false and multi-cycle paths where they don't belong. This can also be due to design changes, misunderstanding 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, a 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.

The key areas where of Gate Level Simulation complements the efforts are:

Verify the functionality of the design: GLS can help verify the functionality of a digital design by simulating the behavior of the gates and flip-flops in the design. It can ensure that the logic is correct and that the circuit operates as intended.

Timing analysis: GLS can help verify the timing of the design by simulating the propagation delay of the gates and flip-flops. It can ensure that the design meets timing requirements and that the circuit operates at the required frequency.

Debugging: GLS can help debug the design by identifying errors or unexpected behavior in the circuit. It can help identify timing violations, glitches, and other issues that may occur in the circuit.

Power analysis: GLS can also be used to perform power analysis on the design, which can help identify areas of the circuit that consume the most power and optimize the design for power consumption.

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.

GLS is also used to collect switching activity for power estimation and correlation, to verify the integration of digital and analog netlists, required to simulate ATPG patterns, generate ATE test vectors, validate EDA tool flow change while moving from one vendor’s sign off tool to another, validate that RTL simulations were not having any undesired force statements from the test bench and masking bugs.

In all cases, getting a GLS up and running is generally accompanied by a series of challenges so frustrating that they invoke a shower of adjectives. There are many sources of trouble in GLS. 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 a gate-level simulation with back annotated SDF.