SANTA CRUZ, Calif. In theory, static timing analysis and formal verification should render gate-level simulation unnecessary. But in reality, it's unavoidable, according to a number of engineers who contributed postings to the latest E-Mail Synopsys Users Group (ESNUG) bulletin.
In the ESNUG 421 bulletin, readers responded to a previous question from an engineer asking how heavily others relied on gate-level simulations. Many respondents replied that gate-level simulation is memory and labor-intensive, but still needed as a "sanity check" to ensure chips are ready for tapeout.
"We all loathe gate-level simulations. We want to banish them from our lives, yet they are still with us," wrote one engineer. He said that gate-level simulation "is a poor way to catch problems, but if you set up your environment with an eye towards making the task easier, it can be invaluable."
Engineers noted that gate-level simulation may be the best way or the only way to catch problems with reset sequences, asynchronous interfaces, and cross-clock domain paths. One engineer said it's needed to verify scan testing. Many others called it a "sanity check" or a "confidence builder" that's needed to complement static timing analysis.
"Static timing analysis is only as good as your constraints," wrote one engineer. "Annotated gate-level sims can be a good sanity check for missing constraints." Another related an incident in which static timing analysis did not find violations because an improper constraint was fed into it. The violations only came to light with gate-level simulation.
Others reported similar incidents. One engineer said that gate-level simulation found that shorter pulses were "swallowed" by some of the slower gates, a problem that did not come to light with the PrimeTime static timing analyzer. Another related a design in which PrimeTime reported no violations, but gate-level simulation found that signals from the core clock domain were clocked into the half-speed clock domain.
"If your chip has system clocks that only talk synchronously with each other, works in a single mode of operation all the time, and your static timing analysis setup includes no constraints, disabled arcs or false paths, then you can cover everything in static timing analysis," wrote one engineer.
Still, one engineer commented that his company ran only very minimal gate-level simulation. "Usually, for us, it's started just before tapeout, and actually doesn't finish until after we've already pulled the trigger," he wrote. "Risky? You bet."
One engineer did say he had cut out gate-level simulation for his FPGAs. "We did about 30 designs and never had a problem that would have been caught by gate-level sims," he wrote. "In my view, if you can do good static timing analysis inside each clock domain and be really careful checking the clock domain boundaries, you should be okay."