What is Gate Level Simulation (GLS) ?
Gate Level Simulation (GLS) is a crucial step in the digital design verification process, occurring after the synthesis of the Register Transfer Level (RTL) code. It involves simulating the behavior of a circuit at the gate level, using a netlist that represents the circuit in terms of logic gates and their interconnections.
How is it different from RTL simulations ?
Unlike RTL simulations, which typically operate in a zero-delay environment, GLS can incorporate timing delays. These delays can be specified using Standard Delay Format (SDF) files, allowing for more accurate modeling of real-world behavior where propagation delays and signal integrity are critical.
What are different GLS delay modes ?
GLS simulations are run on a post-synthesis netlist where cell and path delays may or may not be annotated.
- Zero Delay Simulation: In this mode, no timing delays are considered, making it faster but less realistic.
- Unit Delay Simulation: A simple delay model is applied, where each gate has a uniform delay.
- SDF Simulation: This mode uses detailed timing information from an SDF file to simulate actual delays in the circuit.
Why is GLS run ?
There are several reasons to conduct GLS, although many companies evaluate the effort involved against the likelihood of uncovering actual bugs, depending on the complexity of the design.
- Verify ECOs: Design Engineering Change Orders (ECOs) implemented in the netlist after synthesis can only be verified through Gate Level Simulation (GLS).
- CDC Paths: GLS is essential for ensuring that signals transitioning between different clock domains are processed correctly, as it can identify issues such as metastability, data corruption, and timing violations that may occur during these crossings.
- Reset/Initialization Verification: Gate Level Simulation (GLS) is utilized for testing reset sequences, power-up conditions, and system initialization. It verifies whether the design has any unintended dependencies on initial conditions. For effective verification, GLS necessitates a complete reset of the design.
- X Optimization in RTL: Simulators often optimistically assign values of 0 or 1 to signals, which the gate level simulator may interpret as "X." This can lead to bugs in the RTL due to the propagation of these X values within the design. Such issues can only be identified through Gate Level Simulation (GLS).
- Asynchronous path timing Verification : STA does not check the asynchronous paths and has constraints for false and multicycle paths. GLS is important to check this asynchronous path functionality and also to confirm if the contraints are correct.
- Low Power and DFT Scan chain structure: During the Netlist creation several new structures are added for Lower power and Scan chains for DFT testing. GLS helps to test these new structures in the netlist if required along with making sure the netlist still works functionally as expected.
- Verify Glitches on Edge Sensitive Signals : Design can generate glitches due to combinational logic and clock tree delays. GLS can help to identify and fix these signals by running the simulation using both best and worst case timings .
What are some of the challenges ?
- GLS simulations are inherently more complex than RTL simulations due to the detailed representation of gates and their interactions. This complexity results in longer simulation times and higher memory requirements.
- Modern logic simulators operate on an event-driven basis, meaning they only update the state of the design when an event occurs (e.g., clock edge or input change). This can make the simulations slower and may take hours to finish depending on design complexity.
- Debugging issues in GLS can be challenging due to potential initialization problems and X propagation (unknown states).
