Gate Level Simulation: Ensuring Chip Functionality and Timing

While Register Transfer Level (RTL) simulation plays a vital role in verifying the high-level functionality of a design, it is often insufficient to catch all potential issues. This is where gate-level simulation (GLS) steps in as an important verification step, providing a more detailed and realistic view of the design’s behaviour before it is sent to manufacturing. GLS is a process where a design is simulated after it has been synthesized into a netlist of logic gates. It verifies the functionality of the design at the gate level, ensuring it matches the expected behaviour and timing behaviour of the design. 

Motivations for GLS: 

The primary motivations for GLS include: 

• Accurate Timing Verification: Unlike RTL simulations, GLS provides a much more accurate representation of the circuit’s behaviour with real delays in place. GLS is necessary to verify the timing of the design, including propagation delays of gates and flip-flops. It can ensure that the design meets timing requirements. 
• Asynchronous Path Verification: GLS is particularly important for verifying asynchronous paths, which are not thoroughly analysed by static timing analysis (STA). 
• Detection of Issues Missed by RTL Simulation: GLS can identify glitches, race conditions and other issues that are difficult to catch in RTL simulation. 
• Verification of System Initialization and Reset: GLS helps in ensuring that the system initializes and comes out of reset correctly, which is a critical aspect of design verification. 
• DFT Verification: Because scan chains are usually inserted after RTL synthesis, gate level simulation is needed to verify that these structures are correctly implemented. 
• Power Estimation: GLS is essential for power estimation, providing insight into areas that consume the most power so that they can be optimized for power efficiency. 

GLS Execution Process: 

The typical GLS process involves several key steps: 

• Synthesize RTL to a gate-level netlist: The RTL design is verified to ensure correct functionality, and the verified RTL code is converted into a gate-level netlist using synthesis tools. 
• Create or adapt a testbench:  The testbench may need updates for GLS, like turning off timing checks on synchronizer flops to avoid redundant debugging. Non-resettable flops also have to be initialized to prevent X corruption.  
• SDF Annotation: Timing information in the form of a Standard Delay Format (SDF) file is added to the gate-level netlist. The SDF file contains delay information for cells and wires. 
• Simulation: While simulating a Gate-Level design, the test suite is carefully selected. Initially, Zero-delay or Unit-delay SDF simulations are performed for testbench cleanup, followed by GLS runs with full SDF timing. 
• Analysis and Debugging: Results are analysed and issues, such as X-propagation, timing violations and other errors are debugged. 

Preparing the Testbench: 

To run GLS, significant modifications are required in the testbench.  

• GLS is particularly sensitive to unknowns (X-states), as well as to initial conditions, making it necessary to update initialization sequences to properly configure the chip.  
• Initialize all Non-Resettable Elements to All-0s, All-1s and Random 
• Ensure all floating inputs have Pull-ups or Pull-downs. Many testbenches do not drive all the inputs to their DUT and a Z quickly becomes an X in GLS. 
• All hierarchical references in the design must have corresponding versions for both RTL and GLS. To make this work, plusargs need to be added while running simulation and probably `ifdefs for GLS specific constructs. All assertions are required to be updated for GLS specific timing. 
• Review and remove all force statements applied to RTL internal signals, as signal names and hierarchical references may change. 

Preparing the Test plan 

There could be hundreds of test cases in Functional Simulation. However, not all tests can be performed in GLS. Choosing a selection of test cases that offer the most benefit is crucial because of the complexity and lengthy runtimes of GLS. Every feature of the block should be covered in the test selection process. Priorities testcases that cover following key areas:  

• Initialize and boot-up sequences 
• Every design block should contain a minimum of one testcase that covers the block’s functionality 
• PLL Locking procedures 
• Check various clock ratios 
• Exercise all external interface on the chip 
• Asynchronous reset assertion and de-assertion  
• Verify memory map and register access 
• Verify all power modes of the design 

Modifying Simulation Script 

• Update scripts for handling different GLS modes (RTL simulation, Zero-delay and SDF timing simulations). 
• Modify scripts to execute GLS runs according to the tool’s requirements. 

Running Regressions 

There is no need to rerun most RTL regression tests in gate-level simulations. Avoid unnecessary tests, as GLS runs are time-consuming. Instead, carefully select a small, critical subset of the regression suite that truly covers functionality, ensuring efficient and meaningful verification.

Debugging Failures 

Here are some of the key debugging challenges in gate-level simulation: 

1. X propagation: This is one of the most common and significant challenges in GLS debugging. X values represent unknown or uninitialized states in a simulation. Unlike RTL simulations which may mask X values by converting them to 0 or 1, GLS is pessimistic and will propagate X values, potentially leading to test failures. Debugging X propagation requires tracing the source of the ‘X’ and forcing the affected signals to a known value (0 or 1). X propagation can be caused by various issues such as: 
   

• Uninitialized memory 
• Non-resettable flip-flops (NRFs). If NRFs are not properly initialized, they can cause X values, which will then propagate through the circuit. 
• Timing violations, such as setup, hold, or width violations. 
• Glitches on edge-sensitive signals.  

2. Timing issues: GLS includes timing information, which can reveal timing-related problems that are not present in RTL simulations.
   • Glitches: These are unwanted transient signals that can occur due to timing delays and GLS can identify glitches on edge-sensitive signals. 
   • Race conditions can also occur due to timing delays. 
   • False paths are logic paths that are unlikely to be exercised in real-world scenarios and can cause timing issues if not properly identified 
   • Multi-cycle paths which are paths with delays across multiple clock cycles, can also cause issues if not properly analysed 
   • Asynchronous Paths are not analysed by STA and can cause timing violations in GLS if not properly handled. 
   • Setup and hold violations which can cause functional mismatches. 
   • Clock domain crossings require synchronizers to avoid issues and GLS can help reveal where these synchronizers are needed. 

Simulation Time:  

GLS is computationally expensive and can take a long time to run, especially for large and complex designs. The detailed gate-level simulation with SDF (Standard Delay Format) back annotation leads to significantly longer runtimes. 

Types of GLS:  

1. Zero Delay Simulation 

This simulation runs the netlist without applying any timing data. It ignores specify block delays using the -nospecify switch or -delay_mode zero. It is primarily used for system initialization, reset sequences and verifying power-up and reset operations. This step is not compulsory but generally very fruitful in the GLS execution. (xrun -nospecify or -delay_mode zero) 

2. Unit Delay Simulation  

In this simulation, every element operates with a fixed unit delay (-delay_mode unit). It offers a simpler alternative to SDF back annotation and helps in detecting race conditions and combinational loops. 

3. SDF back annotation Simulation  

This is the most used gate-level simulation. It applies delays to gates and nets based on extracted Static Timing Analysis (STA) data. This method is essential for verifying target frequency operations, glitch detection and power estimation. The $sdfannotate(<design_name>.sdf, DUT,,”sdf.log”,”MAXIMUM”) command in RTL is used to apply these delays. SDF (Standard Delay Format) files contain minimum, typical and maximum delay values for a design. These values represent the range of expected delays for gates and interconnects within the circuit. Here’s a breakdown of how these values are used: 

• Minimum (Min) Delays: Represent the shortest possible delay through a gate or path. This is often referred to as the best-case scenario (BC). 
• Typical (Typ) Delays: Represent the most common or average delay through a gate or path. 
• Maximum (Max) Delays: Represent the longest possible delay through a gate or path. This is often referred to as the worst-case scenario (WC).  

Conclusion: 

Gate Level Simulation (GLS) is crucial for verifying various aspects of a design that may not be thoroughly checked in RTL simulations. It helps in identifying issues such as X-propagation, timing violations and identifies glitches that may not be visible at the RTL level. 

By performing Zero-delay simulations first, testbench setup issues like floating signals, uninitialized memory, non-resettable flops and hierarchy mismatches are addressed.  

SDF-based timing simulations further validate the design under real-world conditions, covering worst-case corners to catch setup and hold violations. 

GLS is an essential, yet complex, design verification step that provides high confidence in the functionality and timing of a design before tape-out. Effective planning, testbench setup and debugging strategies are very important to overcome the challenges and make the most of GLS in modern chip design.