Even today, gate-level simulation is still a major signoff step for most semiconductor projects. However, those simulations can take days or weeks to run. A bug that causes a rerun of a gate regression can push a tapeout for weeks—but help is on the way!
The app note for gate-level simulation (GLS) methodology was released on [DATE]. It aims to showcase new methods and simulator-use models that make GLS more productive, with emphasis on a few strategies to make GLS more effective. The thought of spending weeks on GLS simulation may loom large over your design time-frame, but have no fear: this app note is the knight sent to help you slay the GLS dragon.
So, why care about reducing GLS runtime and memory? Well, as process technologies improve, allowing for smaller, more gate-dense dense chips—from 65 nm to 40 nm, and soon to 28 nm—teams are finding that more GLS cycles are required to reach signoff. Below 40 nm, new timing rules exist; and this creates a need for more GLS cycles as well. Despite the growing need, GLS simulations require huge servers with massive memory and runtime, which lays a serious strain on closure cycles.
The contents of this app note are as follows:
Table of Contents
Abstract - 4
Gate-Level Simulation Flow Overview - 5
Why Gate-Level Simulation Is Required - 6
Techniques to Improve Gate-Level Performance - 6
Improving Gate-Level Simulation Performance with Xcelium Simulator - 6
- Applying More Zero-Delay Simulation - 6
- Improving the Performance of Gate-Level Simulation with Timing - 15
- Improving Performance in Debugging Mode - 20
- Other Useful Xcelium Simulator Gate-Level Simulation Features - 21
- Improving Elaboration Performance Using Multi-Snapshot Incremental Elaboration (MSIE) - 23
- Accelerating Gate-Level Simulations - 24
A Methodology for Improving Gate-Level Simulation - 27
- Effectively Use Static Tools Before Starting Gate-Level Simulation - 27
- Controlling or Handling Timing Checks Based on STA Reports - 37
- Focusing on Limitations of Static Timing Analysis and Logical Equivalence Tools - 39
- Using DFT Verification - 39
- Catching Gate-Level Simulation X Mismatches at RTL Using Xcelium Simulator X-Propagation Solution - 46
- Blackboxing Modules Based on the Test Activity - 47
- Saving and Restarting Simulations - 47
- Hybrid Mode - 48
Library Modeling Recommendation - 49
Summary - 51
As an example, one of the techniques used to improve GLS performance is to run more zero-delay simulations. Simulations in zero-delay mode run a lot faster than they would normally, so running more zero-delay simulations while the design is still in the timing closure process can make sure that the design functions correctly. In Xcelium Simulator, you can control delay values through command-line options and compiler directives, so it’s easy to customize.
The app note also offers tips for improving GLS results that are simulator-independent. It offers advice on using static tools—like linting and static timing analysis (STA)—to reduce gate-level verification time. STA tools can do both hierarchical timing analysis and SDF generation. Based on the reports from the STA tools, one can handle timing checks differently.
Beyond that, gate-level DFT verification can be used to check test structures put in place by specific DFT tools, like ModusTM Test. The app note runs through a list of tips and tricks for ensuring the thorough, fast, and painless running and debugging of DFT simulations, including simulation with netlists, functional equivalency checks, tips for ensuring that timing requirements have been met, and more.
To begin your quest to slay the GLS dragon, check here.