You are on page 1of 6

Gate level simulations

:
verification flow and
challenges
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)
(b)
(c)

Transistor level
Gate level
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.

Testcases checking clock source switching. The possible candidates for this list are:          Testcases involving initialization. Also. It is a probable method to check the critical timing paths of asynchronous designs that are skipped by STA. or circuit tricks. Asynchronous paths in the design. 11. then they should be coded. 13. To check if design works at the desired frequency with actual delays in place. To check special logic circuits and design topology that may include feedback and/or initial state considerations. it is a good idea to check reset circuits in gate simulation. It will cause “x” propagation on timing violation on that flop. All the blocks of the design must have atleast one testcase for GLS. Also. Should there be no time constraints. Testcases which check entry/exit from different modes of the design. Testbench updates for GLS . Dedicated tests for timing exceptions in the STA. If a designer is concerned about some logic then this is good candidate for gate simulation. To avoid simulation artifacts that can mask bugs at RTL level (because of no delays at RTL level). 10. to check if we have any uninitialized logic in the design which is not intended and can cause issues on silicon. Typically.8. 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. It is a probable method to find out the need for synchronizers if absent in design. boot up. Execution strategy for GLS 1. Could give insight to constructs that can cause simulation-synthesis mismatch and can cause issues at the netlist level. 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 . if there are no tests fulfilling the criteria mentioned above. 9. Preserving design signals Some signals which are critical for GLS debug can be preserved while synthesis. the list of vectors which are to be run in GLS has be selected judiciously. all tests run in RTL simulations can be rerun in GLS. 3. 12. Cases checking clock frequency scaling. 2.Therefore.

change probed logic hierarchy from rtl to gate. otherwise they will cause “x” corruption in GLS. the correct standard cell libraries. need to be picked for GLS. Also. etc.Also. 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 . So when we want that the particular flop should not drive X on the timing violation we generally force its corresponding notifier to '1' or '0' so that it wont propagate X . Unit delay GLS for testbench cleanup This step is not compulsory but is generally very fruitful if employed in the GLS execution. NOTES: The notifier is the value in the specify block that is triggered to possibly cause X output from library cells (gates). X corruption may be caused by a number of reasons such as timing violations. This work should be ideally done before the SDF arrives . Running the unit delay GLS is recommended because one can catch most of the testbench/testcase issues before the arrival of SDF.It may happen that the name of the synchronizers in RTL and the netlist are different. use of uninitialized variables in the testcases that can cause corruption when read via core. 4. 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. There are uninitialized flops in design which by architecture are guaranteed to not cause any problems (if they settle to any value at start). This triggering occurs when you have a timing violation. 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. focus should be more on finding the real design/timing issues. Initialization of non resettable flops in the design One of the main challenges in GLS is the “x” propagation debug. 5. etc). uninitialized memory and non resettable flops . correct models of analog blocks. 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. All such flops should be updated as per netlist . After the SDF arrives. wrong flow of testcase. The timing checks are turned off on all such flops to avoid any redundant debugging.A list of all the synchronizer flops is generated using CDC tools. so we need to make sure that the time does not get wasted in debugging the testcase related issues at that time.

2) sdf: A file which contains all the net delays in the design. 2) Does it really matter if the vcd is of timing simulations or no timing simulations? Because the purpose of the vcd is to only capture the activity triggered by the test. The relationship is as follows: Condition MTM_CONTROL Best Minimum Worst Maximum Typical Typical 3) tcheck file : A file containing a list of all the first flops of the synchronizes in the design where a timing violation is guaranteed and thus taken cared of by the design such as placing synchronizers. 3) Which test is best suited for vcd cut for IR drop? A: The test which claims maximum activity in the design Inputs required: 1) netlist : A backend netlist. A: I think not.Some of the open points are/were: 1) What is IR drop calculation? Why is it done? A: To calculate if the device is safe against the maximum activity of the design. Each entry is of the form: PATH full_hierarchical_path -tcheck 4) no reset flop list : To deposit either 1 or 0 to outputs of these flops to avoid ‘X’ propagation in the design during simulation. The choice of delay is chosen by the parameter MTM_CONTROL in ncsim.An sdf has 3 kinds of delay for each net as <min:typ:max> (not sure of the order). we assume the flops have both Q .Therefore we dont check timing violations in this path. It should matter much in the calculations. Since we get only the list of flops from synthesis guys.

This could lead to wrong delays in the design and thus wrong timing violations during simulations. Setup Issues There could be several setup issues encountered while setting up a gate level simulation environment. 2. Please go ahead and debug the first violation. I saw some ‘X’ propagation even after using this flag so i safely used the no rst file. Each entry is of the form: deposit full_hierarchical_path. Its delay is zero and thus first flop might face a unwanted timing violations sue to clock skew and data delay. Enable timing checks during elaboration. its done by not including the switch -NoTimingChecks in ncelab. It will give an idea if the environment is properly set up. 1) Setup/Hold violations : There could be several setup/hold violations during the simulation. .r. Such violations are wrong and can be avoided by delaying the input w. In ncsim.t the clock. Please check if :  Your sdf is properly annotated and there are no errors/warnings which are terminating the annotation process prematurely.  The Pins that are driven directly by the testbench might cause a timing violation on the first encountered flop in the design as your testbench might be using the same clock to generate the data which is used to capture the data in the design.1'b0 -relative Take Care 1. This should also be achieved by flag NC_INITIALIZE during elaboration which also serves the same purpose but i observed that this flag didn’t work for me.and QN pins and deposit 1’b0 and 1’b1 respectively.Q . In this case since the testbench in pure RTL. Compile all the netlists and library RTL without the -functional switch defined otherwise “no-timing” code will be compiled.

2) ‘X’ propagation : If you see no timing violations and still see an X propagation in the design. . Please check if:  All your non resettable flops are properly initialized to either 1’b0 and 1’b1.  Any timing violation that occurs before the design comes out of reset should be safely ignored. timescale directive is properly set according to delays mentioned in your files. The list of non resettable flops is complete.