Gate level simulation - Introduction


With wide acceptance of STA and Formal verification tools by the industry, one question still arises in the minds of many, "Why do we need gate-level simulation?"

The common reasons quoted by many engineers are simple.
  1. To check if reset release, initialization sequence, and boot-up is proper.
  2. Since Scan insertions occur during and after synthesis, they are not checked by simulations.
  3. STA does not analyze asynchronous interfaces. This is used to validate the constraints used in STA and LEC. Static verification tools are constraint-based and they are only as good as the constraint used. Unchecked use of wildcards and late design changes not propagating to constraints or incorrect understanding of the design require validation of these constraints.
  4. Unwarranted usage of wild cards in static timing constraints set false and multi-cycle paths where they don't belong. This can also be due to design changes, misunderstanding or typos.
  5. Usage of create_clock instead of using create_generated_clock between clock domains.
  6. For switching factor to estimate power.
  7. X's in RTL sim can be pessimistic or optimistic. Any unintended dependencies on initial conditions can be found through GLS.
  8. Design changes, a wrong understanding of the design can lead to incorrect false paths or multicycle paths in the constraints.
  9. Can be used to study the activity factor for power estimation.
  10. It's an excellent feel-good quotient that the design has been implemented correctly.
Some design teams use GLS only in a zero-delay, ideal clock mode to check that the design can come out of reset cleanly or that the test structures have been inserted properly. Other teams do fully back annotated simulation as a way to check that the static timing constraints have been set up correctly.

GLS is also used to collect switching activity for power estimation and correlation, to verify the integration of digital and analog netlists, required to simulate ATPG patterns, generate ATE test vectors, validate EDA tool flow change while moving from one vendor’s sign off tool to another, validate that RTL simulations were not having any undesired force statements from the test bench and masking bugs.

In all cases, getting a gate-level simulation up and running is generally accompanied by a series of challenges so frustrating that they invoke a shower of adjectives. There are many sources of trouble in gate-level simulation. This series will look at examples of problems that can come from your library vendor, problems that come from the design, and problems that can come from synthesis. It will also look at some of the additional challenges that arise when running a gate-level simulation with back annotated SDF.

{ 2 Reactions ... read them below or write one }

Anonymous said on July 2, 2009 at 11:44 AM

where can I find the rest of the articles (sources of trouble, challenges etc.) ???

Niszczarka Wallner said on October 3, 2012 at 8:18 PM

Good introduction. Post was helpful. thanks!

Post a Comment

Your comments will be moderated before it can appear here.