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
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
