One reason for running gate-level simulation is design for test (DFT).

Because scan chains are inserted after the gate-level netlist is created, gate-level simulation is often used to determine whether scan chains are correct . Another motivation for gate-level simulation is that technology libraries at 45 nm and below have far more timing checks, and more complex timing checks, than olde r process nodes. to observe the glitches, and glitches may occur because of issues with simualtio n or logic timing voilations like setup,hold,recovery .... functianlity check ..because of mismatch between rtl & gate list .. DFT insertion should not effect the functionality

sta cannot find glitches ..since sta is not dynamic in nature. logic equivalence check behaves just like synthesis ....so it may not find misma tches between rtl & gate level netlist

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------What we need to check in GLS: 1) check timescale is correct or not 2) check PLI/DLL configurations are correct or not & clock is togging correctly or not with respect to configurations(check duty cycle,arrival time ...) 3) GLS with zero-delay mode: a) To find the filp-flops/latches which are not initialized with any values during reset/set . b) Since logic equivalence check behaves just like synthesis tool, we need to run in zero-delay mode

in order to find simulation and synthesis mismatch c) To conclude that , DFT insertion is correct d) if u want to check a multicycle path/false path/asynchronosus path in ful l timing mode , run the testcase in zero delay mode to check whether this testcase is activating the required(our targeted path) path or not. Note: i) Concentrate on zero-delay loop backs, race conditions ii) Concentrate on initial values of inputs,inouts before occurence of r eset. iii) concentrate on flipflops/lathces that are not initialized with any v alues during reset/set , if any flipflop or latch is not initialized ,then we ca n a X's. see the chip initialization sequence & observe the sequence under full-timing si mulation & also in zero-delay ideal clock simulation See whether IO timings are correctly implemented or not

check whether every filpflop is initalized or not during reset condition case 1: synchronous reset all fipflops should initialize at almost same time case 2: Asynchronous reset a) reset active period is minimum(glitch) now also, all fipflops should initialize at almost same time b) reset active perios is maximum now also, all fipflops should initialize at almost same time e.g : output of one flipflop is an input to another filpflop , since first f/f g ot reset in advance , so first ff gets default value , and if data propagates faster than rese t, then system enter into different state ..