Gate level simulations: verification flow and challenges

, & -March 05, 2014

Introduction

Simulations are an important part of the verification cycle in the process of hardware designing. It can be performed at varying degrees of physical abstraction:

(a)    Transistor level
(b)    Gate level
(c)    Register transfer level (RTL)

In many companies RTL simulations is the basic requirement to signoff design cycle, but lately there is an increasing trend in the industry [1] to run gate level simulations (GLS) before going into the last stage of chip manufacturing. Improvements in static verification tools like Static timing analysis (STA) and Equivalence Checking (EC) have leveraged GLS to some extent but so far none of the tools have been able to completely remove it. GLS still remains a significant step of the verification cycle footprint. This paper focuses mainly on the steps to run GLS from verification perspective and the challenges faced while running it.

Firstly, let us look at the reasons why GLS is still used in the industry despite all the challenges associated with its execution.

Motivation for running gate level simulations

The main reasons for running GLS are as follows:
  1. 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.
  2. To give confidence in verification of low power structures, absent in RTL and added during synthesis. 
  3. It is a probable method to catch multicycle paths if tests exercising them are available.
  4. Power estimation is done on netlist for the power numbers. 
  5. 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. 
  6. Tester patterns (patterns to screen parts for functional or structural defects on tester) simulations are done on gate level netlist.
  7. To help reveal glitches on edge sensitive signals due to combination logic. Using both worst and best-case timing may be necessary.
  8. It is a probable method to check the critical timing paths of asynchronous designs that are skipped by STA.
  9. To avoid simulation artifacts that can mask bugs at RTL level (because of no delays at RTL level).
  10. Could give insight to constructs that can cause simulation-synthesis mismatch and can cause issues at the netlist level.
  11. To check special logic circuits and design topology that may include feedback and/or initial state considerations, or circuit tricks. If a designer is concerned about some logic then this is good candidate for gate simulation. Typically, it is a good idea to check reset circuits in gate simulation. Also, to check if we have any uninitialized logic in the design which is not intended and can cause issues on silicon.
  12. To check if design works at the desired frequency with actual delays in place.
  13. 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.

Execution 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.
  • Testcases which check entry/exit from different modes of 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

It must also be made sure that the test cases selected to be run in GLS are targeting the   maximum desired operating frequency of the design. Should there be no time constraints, all tests run in RTL simulations can be rerun in GLS. Also, if there are no tests fulfilling the criteria mentioned above, then they should be coded.

2. Preserving design signals

Some signals which are critical for GLS debug can be preserved while synthesis.

3. Testbench updates for GLS

A list of all the synchronizer flops is generated using CDC tools. Also, other known 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.

4. Initialization of non resettable 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 and non resettable flops . There are uninitialized flops in design which by architecture are guaranteed to not cause any problems (if they settle to any value at start). Thus, there is a need to find out all such flops in the design (which are reviewed with designers) and initialize them to some random value (either 0 or 1) so as to mimic silicon.

5. Unit delay GLS for testbench cleanup

This step is not compulsory but is generally very fruitful if employed in the GLS execution. The setup is done for unit delay GLS (no SDF) and the testcases that are planned to be run on gate level are run with this setup to clean the testbench. This is done because the unit delay simulations are relatively faster (than those with SDF) and all the testbench/testcase related issues can be resolved here (for example -  change probed logic hierarchy from rtl to gate, wrong flow of testcase, use of uninitialized variables in the testcases that can cause corruption when read via core, etc). Running the unit delay GLS is recommended because one can catch most of the testbench/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.

Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES