Gate level simulations Trends and Pedagogy

Gate level Simulation is used to boost up the confidence about the implementation of a design and can help to verify a dynamic circuit behavior which cannot be verified accurately by static methods. It is a significant step of the verification process.GLS overcomes the Static Timing Analysis limitations and is increasing due to low power issues, complex timing checks at 40nm and below, design for test (DFT) insertion at the gate level, and low-power considerations. For the DFT, scan chains are inserted after the gate-level net list is created; gate-level simulation is often used to determine whether scan chains are correct.

Technology libraries at 45nm and below have far more timing checks, and more complex timing checks, than older process nodes. Gate-level simulation may take up to one-third of the simulation time, and could potentially take most of the debugging time. Gate-level simulation is run after RTL code is simulated and synthesized into a gate-level net list. Gate-level simulation requires a complete reset for the design.

The reasons for running gate-level simulation are Reset Verification, X Optimism in RTL, Timing Verification on Multi-Cycle/Asynchronous Paths and the Basic Heart-Beat Test. In the reset Verification, where the Gate-level simulation can verify system initialization and show that the reset sequence is correct. In X Optimism in RTL, where an RTL simulator may "optimistically" assign a 0 or 1 to a value that a gate-level simulator would identify as X (unknown). In timing Verification on Multi-Cycle/Asynchronous Paths, Static timing analysis can't identify asynchronous interfaces, and has constraint requirements that impact false and multi-cycle paths. In the Basic Heart-Beat Test where some verification teams want to run a very limited sanity check to verify functionality at the gate level. As gate-level simulation runs much more slowly than RTL simulation, it potentially has a significant impact on the verification closure cycle.

 Methodologies for Improving Gate-Level Simulation

Use of the Static tools like linting and static timing analysis, to reduce gate-level simulation time. Linting, for example, should be used before running zero-delay information. Static timing analysis can provide information that's used to start gate-level simulation with timing early in the flow.

GLS is used to give confidence in verification of low power structures, absent in RTL and added during synthesis. It is a probable method to catch multicycle paths if tests exercising them are available. Power estimation is done on net list for the power numbers. To verify the power up and reset operation of the design and also to check that the design does not have any unintentional dependencies on initial conditions. To verify DFT structures absent in RTL and added during or after synthesis. Scan chains are generally inserted after the gate level netlist has been created. Hence, gate level simulations are often used to determine whether scan chains are correct. GLS is also required to simulate ATPG patterns. Tester patterns simulations are done on gate level netlist.To help reveal glitches on edge sensitive signals due to combination logic. Using both worst and best-case timing may be necessary.To check special logic circuits and design topology that may include feedback and/or initial state considerations, or circuit tricks. To check if design works at the desired frequency with actual delays in place. It is a probable method to find out the need for synchronizers if absent in design. It will cause “x” propagation on timing violation on that flop.

 GLS Execution strategy

In highly integrated products, it is not possible to run gate simulation for all the SoC tests due to the simulation and debug time required .Therefore, the list of vectors which are to be run in GLS has be selected judiciously. The possible candidates for this list are test cases involving initialization, boot up, and all the blocks of the design must have at least one test case for GLS, Testcases checking clock source switching.Cases checking clock frequency scaling. Asynchronous paths in the design, Testcases which check entry/exit from different modes of the design, dedicated tests for timing exceptions in the STA.

 GLS are targeting the  maximum desired operating frequency of the design. Some signals which are critical for GLS debug can be preserved while synthesis.A list of all the synchronizer flops is generated using CDC tools. Asynchronous paths where timing checks needs to be turned off are analyzed and complete list of such flops is prepared which also includes reset synchronizers. The timing checks are turned off on all such flops to avoid any redundant debugging, otherwise they will cause “x” corruption in GLS. This work should be ideally done before the SDF arrives .It may happen that the name of the synchronizers in RTL and the netlist are different. All such flops should be updated as per netlist .Also, the correct standard cell libraries, correct models of analog blocks, etc. need to be picked for GLS.

Unit delay GLS for test bench cleanup setup is done for unit delay GLS and the test cases that are planned to be run on gate level are run with this setup to clean the test bench. This is done because the unit delay simulations are relatively faster and all the test bench/testcase related issues can be resolved. Running the unit delay GLS is recommended because one can catch most of the test bench/testcase issues before the arrival of SDF. After the SDF arrives, focus should be more on finding the real design/timing issues, so we need to make sure that the time does not get wasted in debugging the testcase related issues at that time.

The challenges in GLS are the “x” propagation debug. X corruption may be caused by a number of reasons such as timing violations, uninitialized memory and non resettable flops. There are uninitialized flops in design which by architecture are guaranteed to not cause any problems There is a need to find out all such flops in the design and initialize them to some random value (either 0 or 1) so as to mimic silicon. It gives a clear picture of how the design will behave at the desired frequency with actual delays in place. Although GLS has its own set of challenges like setup issues, long run time, etc., it is still very much a part of the sign-off process.

Sources of X in simulation

Missing simulation models or other error in simulation setup.

For any input or bidirectional pin where signal on outside is undriven or tristated.

Simulation model for IO buffer will propagate X into design.

Some PLL simulation models output X on its clock inputs .

Integrated clock gating cells where clock enable input of cell is X may output X on its output clock.

 Setup/hold timing violation on a flop

 Clock domain crossing

  Contention

Timing of reset-to-q arc of a flop is not met

Asynchronous signals directly being used in some logic

Catching X propagation issues at RTL saves time and reduces uncertainty.

Engineers running GLS can temporarily fix these violations in SDF through the STA tools while the timing closure team fixes the root issue in parallel.Setup and hold violations are typical failures that can be noted and worked around to allow GLS process to continue.

Overcome X issues

if statement for sequential

case x and case z statements adds pessimism

case statements

non resettable flops/latches

avoid glitches and testbench coding guidelines

synchronize all asynchronous elements

Fixing quickly

1. Eliminate all Xs.
2. Perform artificial random initialization of uninitialized flops.
3. Manual analysis.

Effects

RTL simulation 

False code coverage 

Functional non-equivalence

Unnecessary debugging in verification

Feedback

Thanks to Test and Verification Solutions who has been a leader in Verification and GLS

Ramdas Mozhikunnath, Experienced ASIC Verification Engineer , 16+ years exp, Intel Alumni

Answered Jul 28, 2017 · Author has 1k answers and 2.5m answer views

Good answer from Manikanta Mashetti which seems to list most of cases.

Two more good references if you want to read a little more

1. Why Run Gate-Level Simulations? - Electronics For You
2. Gate Level Simulation Methodology - A good White Paper from Cadence