Why Gate Level Simulation (GLS)?
• In many companies RTL simulations is the basic requirement to signoff design cycle, but lately there is an increasing trend in the industry to run GLS before going into the last stage of chip manufacturing.
• GLS can catch issues that static timing analysis (STA) or logical equivalence tools (LET)are not able to report.
• To avoid simulation artifacts that can mask bugs at RTL level (because of no delays at RTL level).
• 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
Strategy for GLS :
1. Planning the test-suite wisely to be run in GLS
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:
• Testcases involving initialization, boot up.
• All the blocks of the design must have atleast one testcase for GLS.
• Testcases checking clock source switching.
• Cases checking clock frequency scaling.
• Asynchronous paths in the design.
• Dedicated tests for timing exceptions in the STA.
• Patterns covering multi clock domain paths in the design.
• Multi reset patterns are a good candidate for GLS.
• Stress test.
2. Preserving design signals
• Ensure critical signals and ports for GLS debug preserved while synthesis / not.
3. Testbench updates for GLS
A list of all the synchronizer flops is generated using CDC tools. 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.
• correct standard cell libraries,
• correct memory need to be picked for GLS.
• This work should be ideally done before the SDF arrives.
4. Initialization of non re-settable flops in the design
One of the main challenges in GLS is the “x” propagation debug. X corruption may be caused by a number of reasons such as
• timing violations,
• uninitialized memory
• non re-settable flops.
5. GLS for testbench ENV cleanup
• Zero and Unit –Delay simulation This step is not compulsory but is generally very fruitful in the GLS execution.
• 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.
Types of GLS
• Zero delay.
• Unit delay.
• SDF Timing (MTM type)
• Min(Best Case)
• Max (Worst Case)
• Typical
Outcome of GLS Activity.
• To help reveal glitches on edge sensitive signals due to combination logic.
• It can catch multi-cycle paths if tests exercising them are available.
• It can check the critical timing paths of asynchronous designs that are skipped by STA.
• To check if design works at the desired frequency with actual delays in place.
• Power estimation can be done on netlist with Stress test.
e.g. For switching factor to estimate SOC power calculation. (radhawk tool vcd-> max. power number calculation)
• Verifying system initialization.( Non re-settable flop list to be initialize.)
Note: Don’t use simulator specific switch for initialization. It will hide issues.
