Gate Level Simulation Part 2

Here, I am sharing some useful learning and setup details for DV. Mostly, GLS activity starting at last phase or near tap-out. By considering time to market with quality. we should complete GLS activity smart and effectively. I have already shared few key points like smart test suit selection, environment clean-up or confident before final post-layout netlist. GLS activity is really helpful to catch and resolve ECO at early stage before tap-out.

• Zero & Unit delay simulation : This step is not compulsory but generally very fruitful in the GLS execution. Before arriving final netlist. we can ensure environment clean-up.

• SDF Timing (MTM type) • Min(BC) • Max (WC) • Typical : 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 setup and testcase related issues at that time.

Useful setup details:

1. SDF Annotation: sdf file contains design delay(MIN:TYP:MAX) details. sdf_annotate cmd will annotate sdf delay details to design.

Syntax:
$sdf_annotate(["<sdffile>"], [<instance>], ["<config_file>"], ["<log_file>"], ["<mtm_spec>"], ["<scale_factor>"], ["<scale_type>"]);

Note: sdf cmd file is another way of applying annotation. Required cmd file and setup change, need to plug. 

2. Timing check off for sync flop in design: 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. Therefore we don't check timing violations in this path.

Syntax: PATH full_hierarchical_path -tcheck

CLKA is running on high rate compare to CLKB. so FB1 and FB2 (sync-flop)
FB1-DB1 entering to metastable state. it can corrupt related path/ logic. so, to prevent such
condition. its mandatory to apply timing check off for sync flops.

3. Initialization of non resettable flops: Due to undefined state of flop. Non resettable flops can cause "X" corruption. To prevent such unwanted corruption during gate level simulation. Its necessary to initialize non resettable flops.

syntax:
deposit full_hierarchical_path.Q - 1'b0 -relative 

Note: Don’t use simulator specific switch for initialization (nc_initialize). It can isolate/mask issues
other than non resettable flops. Recommendation to deposit output of non resettable flops.

4. Violations and It’s Analysis: Depends on quality of netlist, design & timing. we can come across following violations. 

• $setup (data_event, reference_event, limit[, notifier]) ;
Data cannot change within the setup time because flip-flops cannot detect the new value.
If data changes within a given time limit, $setup reports a timing violation
• $hold (reference_event, data_event, limit[,notifier]) ;
Data should remain stable for a given time after the active edge of the clock to allow
for propagation of data.
• $width (reference_event, limit, threshold [,notifier]) ;
When width of the active-edge is too small. In FF case it is very important to ensure
that the width of an active-edge is sufficient and FF will work properly.
• $period (reference_event, limit[,notifier]) ;
checks that a period of signal is sufficiently long.
• $recovery (reference_event, data_event, limit, [notifier]) ;
A timing violation occurs if the time interval between an edge-triggered reference event
and a data event exceeds the 'limit'
(time of data event) - (time of reference event) < limit

5.SDF report and warning analysis:

Report : Ideally, it should annotate 100%  

No. of Pathdelays = 8676352  Annotated = 99.14% 

No. of Tchecks = 9695046  Annotated = 97.67% 

Warning: 

• *W,SDFINC: unconnected ports in netlist. 

• *W,SDFNCAP: Assign statements in netlist. 

• *W,SDFCTE: Cell type mismatch. 

• *W,SDFNEP: Unable to annotate to non-existent path 

• *W,SDFNET: Unable to annotate to non-existent timing check 

• *W,SDFNSB: Attempt to annotate specify block data of instance

Tips: There is chance of having functional issue due to MCP (Multi cycle path). Need to stress testing for related functional path. 

 
Please share your valuable inputs, if required more details on any point or any query. 

Gate Level Simulation Part 1

 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.