Forum Discussion
Altera_Forum
Honored Contributor
17 years agoI find fewer and fewer designers doing gate-level simulations. Although it can catch design flaws, it is only a specific subset of flaws. (Gate-level sims were always done by ASIC designers because they were willing to sacrifice a LOT of time doing verification in order to avoid re-spins).
Often I see users doing RTL sims(and spending a lot of time doing putting together a comprehensive testbench). Since RTL sims are often the fastest(no place and route), and quickly identify functional bugs, it's usually worth the effort. After that, rather than doing timing sims, they make sure their Static Timing Analysis is correct. The nice thing about STA is it puts bounds on your signals, i.e. it says a path will work as long as the delays are bounded by some range of values, i.e. a 100MHz clock generally has data delays that must be more than 0ns and less than 10ns, including clock skew. That's an easy example, but it can get more complicated, especially with I/O timing. Once a design passes STA, the timing simulation shouldn't reveal much more. (Timing Simulations have a single delay value, like 7ns, where STA covers a range. Also gate sims don't flag errors except for micro setup and hold violations. For example, if the data delay were 13ns in your 100MHz domain, there would be no warning in the simulation that something was wrong, your data would just get there a clock later, and if that caused a functional problem you would see it later and have to back-track to figure it out.) Finally, once RTL sims and STA are done, SignalTap and other in-system debug tools become crucial. They help identify anything you missed, anything you got wrong(like you may have incorrect I/O timing requirements), or anything you didn't cover in your original testbench. This is slower than RTL simulations, but is absolutely critical because it identifies real bugs, not just simulated bugs. It's being recommended more and more to prepare for this up-front. (E.g. populate a few boards with a larger device, when possible, so that you have more internal logic and RAM to run larger SignalTap runs...)