Gate Level Simulations (GLS)

By Ramesha Parameswaraiah, Director of Engineering, Interex Semiconductor

Introduction to Gate Level Simulations (GLS)

Gate Level Simulation (GLS) is a critical stage in the ASIC design and verification flow. GLS involves running simulations on synthesized and post-layout netlists to validate the functionality and timing behavior of the design before tape-out.

GLS can be executed at both block level and full-chip level. First GLS without timing annotation is run to clean up the flow and to fix any issues related to integration of the netlist with testbench. Once the simulations without timing annotation pass, the simulations with timing annotation are run. 

GLS Without Timing Annotation

Gate level simulations without timing annotation are typically executed in one of the following two modes:

Zero-Delay GLS

In Zero-Delay GLS, all delays in the netlist are made zero.

An example for simulator option used to run Zero-Delay simulations is given below (Cadence xrun): 

xrun -64bit -access +rwc -top <top_module> \

     -timescale 1ns/1ps \

     -delay_mode zero

Unit-Delay GLS

In Unit-Delay GLS, all delays are assigned a fixed unit value, usually a very small delay such as 1ps.

An example for simulator option used to run Unit-Delay simulations is given below (Cadence xrun): 

xrun -64bit -access +rwc -top <top_module> \

     -timescale 1ns/1ps \

     -delay_mode unit

These simulations are primarily used for:

• GLS Setup flow flush
• Identifying any issues related to integration of the netlist with testbench
• Detecting initialization and X-propagation issues
• Verifying DFT and low-power structures added after synthesis

GLS With Timing Annotation

Gate-level simulations with timing annotation are performed by back-annotating the netlist with an SDF (Standard Delay Format) file. These simulations are also referred to as Timing Simulations.

The SDF files are generated by Static Timing Analysis (STA) tools and are generally delivered by the Physical Design (PD) team. An SDF file typically contains:

• Cell delays (rise/fall delays)
• Interconnect delays (net delays)
• Timing checks such as setup, hold, recovery, and removal checks

Timing Simulations are used to validate the timing behaviour of the design before tape-out across multiple Process, Voltage, and Temperature (PVT) corners.

---

Need for Gate Level Simulations

Gate Level Simulations are executed for several important reasons. 

Gate Level Simulations are run to : 

1. Validate the constraints used in Static Timing Analysis (STA) and Logic Equivalence Checking (LEC). Issues in constraints could be because of the following reasons :
   • Typographical errors
   • Incorrect use of wildcards
   • Design changes not propagated into constraints
   • Incorrect understanding of the design intent
2. Verify critical timing paths in asynchronous logic which are skipped by STA.
3. Validate power-up and reset sequences.
4. Ensure that the design does not unintentionally depend on initial conditions.
5. Detect issues masked during RTL simulations because of force statements in the testbench.
6. Verify low-power structures which are added after synthesis, such as:
   • Isolation cells
   • Level shifters
   • Retention registers
   • Power switch cells
7. Verify DFT logic inserted after synthesis
8. Collect switching activity data for power estimation.
9. Generate ATE vectors for manufacturing tests.

Successful execution of carefully selected GLS testcases across multiple timing corners significantly increases confidence in the quality and robustness of the netlist before tape-out.

---

Creating a GLS Setup

GLS is generally executed in three stages:

• GLS on Pre-Layout Netlist with Zero-Delay or Unit-Delay
• GLS on Post-Layout Netlist with Zero-Delay or Unit-Delay
• GLS on Post-Layout Netlist with SDF Back-Annotation

1. GLS on Pre-Layout Netlist with Zero-Delay or Unit-Delay

This stage is primarily used to stabilize the GLS environment and flow.

In this setup:

• RTL is replaced with the synthesized pre-layout netlist
• Technology libraries are included
• Timing checks are disabled

The primary goals are:

• Verifying testbench integration with the netlist
• Debugging setup/flow related issues

Important recommendations:

• All DUT inputs must be driven to known values (‘0’ or ‘1’)
• No DUT input should remain floating or driven to ‘X’
• Memories should be initialized properly to avoid unnecessary X-propagation
• All the non-resettable flops and latches in the design should be initialized with known values (‘0’ or ‘1’)

Note on Initialization of Non-Resettable Flops/Latches

One of the most important steps during GLS is initializing non-resettable flops and latches.

Without initialization, outputs of these elements may remain at ‘X’ from time 0ns, causing extensive X-propagation, simulation failures, or simulation hangs.

For large SoCs, there could be hundreds of thousands of such flops. These are generally extracted using automation scripts.

Initialization of non-resettable flops and latches can be done by depositing known values (‘0’ or ‘1’) on their outputs. Only soft deposits should be used, not forces. 

Example simulator commands for depositing values

Cadence Simulators (Incisive/Xcelium)

 deposit <hierarchical_path> <value>

Questa Simulator

 force -deposit <hierarchical_path> <value>

Non-resettable flops and latches should be initialized randomly with either ‘0’ or ‘1’ to ensure that the design does not unintentionally depend on specific initial values.

2. GLS on Post-Layout Netlist with Zero-Delay or Unit-Delay

The next stage involves running GLS on the post-layout netlist generated after Place and Route (PNR).

In this setup:

• RTL is replaced with the post-layout netlist
• Technology libraries are included
• Timing checks are disabled

As with pre-layout GLS, 

• All DUT inputs and memories should be initialized properly. 
• All the non-resettable flops and latches in the design should be initialized with known values.

3. GLS on Post-Layout Netlist with SDF Back-Annotation

Once Zero-Delay and Unit-Delay GLS are stable, timing simulations with SDF back-annotation are executed.

This setup is similar to Post-Layout GLS with Zero-Delay/Unit-Delay, except that the netlist is back-annotated with SDF timing information.

Important Considerations

• Timing checks must not be disabled.
• Zero-delay specific simulation run time switches such as +notimingchecks (Questa

vsim)/-notimingchecks (Cadence xrun) should not be used.

• Appropriate SDF files must be passed to the simulator.

SDF annotation can be performed as mentioned below:

• Using simulator command-line options
  • Examples for Questa vsim:
    • vsim -sdfmax /tb/dut=design_sdf_max.sdf work.top
    • vsim -sdfmin /tb/dut=design_sdf_min.sdf work.top
  • Examples for Cadence xrun:
    • xrun -sdf max:/tb/dut:design_sdf_max.sdf -top tb
    • xrun -sdf min:/tb/dut:design_sdf_min.sdf -top tb
• Using $sdf_annotate system task
  • Examples :
    • initial begin

    $sdf_annotate(“design_sdf_max.sdf”, tb.dut, , “sdf_max.log”, “MAXIMUM”);

end

• initial begin

    $sdf_annotate(“design_sdf_min.sdf”, tb.dut, , “sdf_min.log”, “MINIMUM”);

end

Synchronizer Timing Checks

Timing violations can occur on the first flop of synchronizers because of asynchronous clock-domain crossings. Therefore, timing checks on the first flop of synchronizers are disabled in case of double-synchronizers. And timing checks are disabled on the first flop as well as second flop in case of the 3 stage synchronizers.

Example simulator command to disable timing check (Questa)

  tcheck <hierarchy> SETUPHOLD off

Alternatively, the following System Verilog System Task can be used :

$disable_timing(hierarchical_instance_path);

Example: 

initial begin

    $disable_timing(tb.dut.sync1_reg);

end

Standard SDF Timing Corners

Physical Design teams generally provide SDF files for multiple timing corners.

1. SDF Min Corner

• Represents best-case timing
• Delays are very small
• Primarily used for hold violations analysis

2. SDF Typical Corner

• Represents nominal timing conditions
• SDF Typical Corner simulations are run for timing sanity check and debugging realistic (nominal) behavior
• They are generally not run as part of final timing sign-off

3. SDF Max Corner

• Represents worst-case timing
• Delays are large
• Primarily used for setup timing validation

Challenges in Gate-Level Simulations

1. Slow Simulation Performance

Timing simulations are significantly slower than RTL simulations.

Waveform dumps and log files can become extremely large, making it impractical to run the complete regression suite.

Recommended GLS tests include:

• Power-up and reset sequence validation
• Initialization tests
• Some basic register read/write tests
• Clock and reset generation tests
• STA timing exceptions validation tests
• Important functionality tests for each block
• Low-power verification tests

2. Race Conditions

Zero-delay GLS simulations are prone to race conditions, which may produce unexpected simulation behavior.

3. Zero-Delay Loops

Some tests may hang because of zero-delay feedback loops in Zero-Delay GLS.

Adding a very small delay in the feedback path generally resolves the issue.

These problems are typically not observed during SDF simulations because real delays exist in the feedback path.

4. Identification of Non-Resettable Flops and Synchronizers

Identifying:

• Non-resettable flops/latches
• First flop of synchronizers

can be challenging in large SoCs.

Although scripts are used to extract these elements, some instances may still be missed and are only discovered during debug.

A good practice is to review extracted lists jointly with design engineers early in the project, so that the scripts can be updated to extract the missing ones which saves un-necessary debug later.

5. Debugging X-Propagation

Debugging X-propagation in GLS is often complex and time-consuming.

The root cause may span multiple blocks and require extensive tracing across large gate-level netlists.

Effective usage of simulator Integrated Debug Environment (IDE) involving:

• Design Browser
• Source Code Viewer
• Schematic Tracer
• Waveform Viewer

can significantly reduce debug effort.

Some of the main reasons for ‘X’ propagation in GLS are mentioned below : 

• DUT inputs are left floating
• DUT inputs are driven ‘X’ from testbench
• Memories within the design are not initialized
• Outputs of non-resettable flops and latches are not initialized with known values (‘0’ or ‘1’). This can happen if complete list of non-resettable flops and latches is not extracted by the scripts.
• In case of Timing Simulations, timing check is not disabled for first flop of synchronizers. This can happen if complete list of synchronizer flops is not extracted by the scripts.
• In case of Timing Simulations, all timing violations (including real timing violations) are source of ‘X’ propagation as the timing simulation models of the cells in the netlist will be designed to drive ‘X’ on their output if the cell’s timing is violated.

Modern simulators also provide advanced X-trace features that can accelerate root-cause analysis.

6. Assertions and Monitors Maintenance

Assertions and monitors developed for RTL simulations may require updates during GLS because:

• Hierarchies can change
• Signal names may differ after synthesis or PNR

Netlist updates may also introduce additional maintenance effort.

7. Timing Violation Debug

Timing GLS simulations may generate a very large number of timing violations.

      Most of the initial timing violations (which are before first 10ns or so) can be ignored as during this initial period, the reset sequence and power-up sequence won’t be complete yet and clocks won’t be stable.

      Timing violations can occur when resets (resets asserted and then de-asserted) are applied in middle of simulation. They can also be ignored as they are expected. 

However, violations observed after:

• reset de-assertion
• complete power-up
• system is stabilized

could be real timing violations and must be discussed with designers.

Common violations include:

• Setup violations
• Hold violations
• Recovery violations
• Removal violations
• Width violations

Proper collaboration between Verification, STA and Design Teams is essential for accurate root-cause analysis.

Conclusion

Gate Level Simulation remains one of the most important sign-off activities in ASIC development.

Although GLS execution and debugging can be time-consuming, it provides critical validation for:

• Timing behavior
• Reset functionality
• Low-power structures
• DFT logic
• Synchronizer handling
• X-propagation robustness

A well-planned GLS strategy combined with carefully selected testcases significantly increases confidence in design quality before tape-out.

References

This article is based on industry-standard Gate Level Simulation (GLS) methodologies, practical ASIC verification experience, and publicly available semiconductor verification resources.