Tuesday, July 12, 2011

Gate Level Simulations : A Necessary Evil - Part 3

The response to the initial 2 posts (Part 1, Part 2) clearly show that GLS touches the career profile of almost all verification engineers. I am wrapping up this 3 part series on GLS with some recommendations that might be of some help if you aren’t already deploying them. Please do drop in an email or comment to share your tips & tricks.

To start, it is important to identify features targeted for GLS in the test plan upfront. Adding functional coverage/assertions to these features is a good practice. To set up GLS, develop the Verilog/VHDL TB (with DUT instantiation) from scratch so as to avoid any exceptions/force statements that might just pass from RTL simulations to GLS. If there is a provision, setup a process to develop/tune test cases for GLS such that all HDL code (DUT, TB & test cases) is compiled once and using ‘plusargs’ different tests can be simulated. The SDF should be compiled once and used for all tests. For initial netlist, whether you use zero delay/unit delay/pre layout SDF, disable timing check and have few smoke tests for sanity checks on the netlist. In case of large gate count, implementation team would be using hierarchical synthesis. If the hierarchy is logical you may want to try segregating GLS test points that are local to the components in hierarchy and try out GLS at that level. For designs that take some initial time to synchronize before the actual feature testing starts (particularly in networking domain), the tests can be developed such that multiple features are clubbed in 1 test. Some level of test case rewriting will save a lot of time during simulations.

Following is a basic common list of tests that most of the teams have in the GLS test suite –
1. Initialization tests i.e. chip coming out of reset and functional in different boot modes
2. Clock, Reset generation and clock dividers
3. Power aware simulations – covering features based on the power format specification
4. Test structures
5. Digital - Analog boundaries
6. Dedicated tests for timing exceptions in the STA
7. Stimulus to each block of the design atleast once

In order to have a controlled rework on the hierachical paths for force statements or monitors, pull out all paths in 1 HDL file under compile directives (e.g. `define in Verilog). This file can be included in the TB and modified/reviewed for every netlist release.

To control the SDF timing on synchronizers –
Enforce naming rules for such modules so that with a perl script you can turn off timing in SDF or through tcl interface to the tool turn off timing checks on selective instances. Where naming convention is not followed, there are some interesting ideas in the following papers –
- My favorite DC/PT TCL tricks, SNUG San Jose 2003
- SoC Gate Level Simulations (GLS) cycle time reduction – Simulation flow enablers, SNUG India 2008.
- Identification of Non-resettable flops for faster Gate Level Simulation, SNUG India 2010.

For debugging, simulation tools have some interesting features that can help narrow down the problem to some extent. A couple of them are – tracing the source of X propagation and expanding time step to highlight the order of execution. With some basic perl scripting you can triage the timing violations report into bins and then chase it accordingly.

Most of the above recommendations have worked well across multiple projects. It would be interesting to know if they hit any limitations in the design space that you work on so that we can discuss further on those specific corner cases for these recommendations.

Hope some of these would help you in your next tryst with GLS.
Happy BUG hunting!!!


Gate Level Simulations : A Necessary Evil - Part 1
Gate Level Simulations : A Necessary Evil - Part 2

7 comments:

  1. One important consideration in writing test cases for GLS is to make sure these test cases are easily portable to the tester environment. Making sure the GLS tests can be converted into test vector for tester will save a lot of effort during the silicon testing.

    ReplyDelete
  2. Hi Eric,

    Thanks much for bringing up this point. Yes, GLS for these tests is just 1 milestone. Some of them actually would need to be ported to the tester env.
    1 tip would be not to drive any signal from the TB asynchronously. Try synchronizing it with the clock to avoid issues when porting on the test.

    ReplyDelete
    Replies
    1. I couldn't find the 2nd and 3rd SNUG paper that you have recommended. From where can I get them..?? Abdul, Amateur in GLS

      Delete
    2. Hi Abdul,

      You should be able tgo locate them on SNUG website. If you aren't able to locate still drop me a meesage on siddhakarana@gmail.com

      Thanks!
      Gaurav Jalan

      Delete
  3. Why is GLS slower than RTL simulation?

    ReplyDelete
  4. You would need to understand some basics on simulators. At a high level, gate level netlist would explode the no. of the nodes evaluating and changing vs. RTL. Secondly it is the timing that gets annotated to the gates & cause further delay.

    ReplyDelete
  5. Excellent article, I just loved it, Very informative, Thanks for your efforts in listing all of them....

    ReplyDelete