Gate Level Simulation (GLS) Interview Questions with Answers

A gate-level simulation (GLS) interview checks whether you know why GLS is still run after equivalence checking and static timing analysis, what inputs it needs (netlist, testbench, SDF and libraries), and how you debug the problems it finds, such as X propagation, reset issues and timing-check violations. This post keeps the original mock-interview opening and adds worked answers to the questions interviewers ask most often, with the follow-ups they use to probe deeper.

Key takeaways

GLS runs the testbench on the synthesized or post-layout netlist, optionally back-annotated with delays from an SDF file.
Equivalence checking proves logic, and STA proves timing against constraints, but neither runs real stimulus through reset, boot, test logic or asynchronous paths. That gap is why GLS survives.
Expect follow-ups on SDF generation, timing checks and notifiers, X pessimism, and synchronizer flops that violate timing on purpose.
Zero-delay, unit-delay and full-timing GLS answer different questions; know when each is used.

The mock interview

A verification engineer claiming mastery in gate-level simulation is coming for an interview.

Interviewer: Welcome
Job Seeker: Thanks
(aliasing I for Interviewer and J for Job-seeker)
I : In your resume you had mentioned that you are an expert in GLS (Gate-level simulation), how comfortable are you.

Read further Here

Note (November 2026): the linked page on the chipdesignart blog now returns "page not found". An archived copy of the gate-level simulation mock interview is available on the Internet Archive. The worked answers below are written for this blog and cover the same ground in more depth.

Worked answers to common GLS interview questions

1. What is gate-level simulation?

GLS is simulation of the design after synthesis, where the RTL has been replaced by a netlist of standard cells (and macros such as memories) from the target library. It can be run on the synthesis netlist before layout or on the final post-route netlist. With timing, the cell and wire delays come from an SDF file; without timing, it is run as a zero-delay or unit-delay simulation.

How interviewers extend this: "At which points in the flow would you run GLS, and why more than once?" A good answer: a zero-delay or unit-delay run on the synthesis netlist to catch synthesis and simulation mismatches early, then SDF-annotated runs on the post-route netlist at the signoff corners.

2. What inputs do you need to run GLS?

The gate-level netlist (synthesis or post-route, including scan and clock tree cells where present).
Simulation models of the standard cells, I/O cells and memories, usually Verilog with specify blocks for timing.
The testbench, often a reduced set of tests chosen for reset, boot, clocking and test modes.
For timing runs, an SDF file for each corner, applied with $sdf_annotate or a simulator option.

3. What is SDF and how is it produced?

SDF (Standard Delay Format, standardized as IEEE 1497) is a text file that holds cell delays, interconnect delays and timing-check limits for each instance in a netlist. It is normally written by the static timing analysis tool or the place-and-route tool after it reads the netlist, the cell timing libraries and the extracted parasitics (usually in SPEF, the Standard Parasitic Exchange Format). One SDF is written per corner, and each delay entry can carry min, typical and max values.

How interviewers extend this: "What happens if some SDF entries do not match the netlist?" The simulator reports annotation warnings or errors; you must read them, because an unannotated cell silently falls back to its default model delay and the run is no longer the timing you think it is.

4. If logical equivalence checking passes, why run GLS?

Equivalence checking (LEC) proves that two representations compute the same logic, for example RTL against the synthesis netlist, or the synthesis netlist against the post-route netlist. It does not check timing, and it only proves what it is told to compare: constraints that disable scan or test modes, black-boxed blocks and incorrect setup can hide real differences. GLS also catches problems that are invisible to both RTL simulation and LEC, such as X values that RTL simulation treated optimistically.

5. If static timing analysis is clean, why run GLS?

STA checks every path against the constraints without stimulus, so it is only as good as those constraints. A wrong false path or multicycle path, an unconstrained asynchronous interface, or a missing clock definition will pass STA and fail on silicon. GLS with SDF exercises the real paths with real sequences: reset assertion and release, clock switching, power-up and boot, and the scan and test modes. It is a cross-check on the constraints, not a replacement for STA.

How interviewers extend this: "So should every test be run at gate level?" No. GLS is slow, so teams pick a focused set of tests and accept that coverage closure is done in RTL simulation.

6. What are timing checks and notifiers?

Cell models contain timing checks such as $setup, $hold, $setuphold, $recovery, $removal and $width. When a check fails, the simulator prints a violation and toggles a notifier register, which the flip-flop model uses to drive its output to X. That X then propagates, so one violation can corrupt the rest of the test.

7. How do you handle synchronizer flops that violate timing on purpose?

The first flop of a clock domain crossing synchronizer samples an asynchronous signal and will see setup and hold violations by design. The usual practice is to disable timing checks, or the notifier X, on those specific instances only, using the simulator's per-instance timing-check controls, while leaving every other check enabled. Switching off timing checks globally hides real bugs.

8. Why do you see X at gate level that you never saw in RTL?

RTL if and case statements treat an X condition optimistically, while gate models propagate X more pessimistically. Uninitialized flops without reset, memories that start as X, and reconvergent X paths all show up at gate level. See the guide to X propagation and how to avoid X pitfalls for the full story.

Zero delay, unit delay and full timing GLS compared

Mode	Delays used	Typical use
Zero delay	None; all cells switch in delta time	Fast functional check of the netlist, scan shift checks
Unit delay	Every cell gets the same small delay	Early netlist runs before SDF exists, removing delta-cycle races
Full timing	Back-annotated from SDF per corner	Signoff checks of reset, boot, test modes and constraint sanity

The middle option is covered in detail in unit delay simulation as an intermediate step in gate-level simulation, and the delay semantics behind all three are explained in transport, inertial and delta delay in VHDL and Verilog.

Mistakes candidates make

Saying GLS "replaces" STA. It complements STA; timing signoff is still done in STA.
Forgetting the libraries and memory models in the list of inputs.
Ignoring SDF annotation warnings.
Turning off all timing checks to get a test to pass.
Not knowing which corner the SDF represents, or that hold problems show up at the fast corner and setup problems at the slow one.

Frequently asked questions

Is GLS still needed in modern chip design flows?

Yes, though it is run on a focused set of tests. It remains the main way to check reset, power-up, clocking, test modes and the correctness of timing constraints with real stimulus.

What is the difference between pre-layout and post-layout GLS?

Pre-layout GLS uses the synthesis netlist with zero, unit or estimated delays. Post-layout GLS uses the routed netlist, which includes clock tree and buffer cells, with SDF delays based on extracted parasitics.

Which tool generates the SDF file?

Normally the static timing analysis tool or the place-and-route tool, from the netlist, the timing libraries and the extracted parasitics.

Why is GLS so slow?

The simulator evaluates every cell and every timing check instead of compact RTL processes, and the netlist can be orders of magnitude larger than the RTL description.

TDEB Top Bar

TDEB Masthead