Timing

Assuming all the important paths are constrained and you've handled any clock domain crossings properly, the static timing analysis is sufficient, and actually more comprehensive than doing a timing simulation. If you meet these conditions, you can be confident that it will behave the same as your functional simulation.

I can count on one hand the number of times I've done a timing simulation, and I've done literally hundreds of high performance FPGA designs.

I concur. The time you could spend on the post PAR simulation is better spent looking at the static timing report and checking you covered all the paths that matter. HTH, Syms.

I mostly agree with Ray and Symon, except with one caveat: Multi-cycle and False path constraints. Since there is no check to ensure that paths that you said were multi-cycle or false actually are so, the only verification left for them is formal analysis or full (post place & route) timing simulation. The only places I've ever had errors show up in full timing simulations were related to incorrectly specified multi-cycle or false paths.

So, if you have multi-cycle or false path constraints, and you're not absolutely sure you have them properly applied so that they cover the paths you intended, and not any paths you did not intend (usually the culprit), then I would recommend a full-timing simulation, but focus on the functions related to those constraints. Everything else is verified by static timing analysis and RTL simulations. Note that RTL simulations are much faster to execute than full timing simulations, especially when the RTL was written in a simulation-efficient manner, where it approaches cycle-based performance.

There are a few formal tools supposedly coming out that can formally verify, or even identify, multi-cycle and false path constraints for you, but I don't have any experience with them.

Andy

Sym> >

Right. It all relies on having the correct static constraints to start with. My own personal methodology for multi-cycle constraints is to code the RTL to make the constraints easy. (Ahem!) So, I use a signal as a global clock enable for the multi-cycle machine, and is _only_ used as a clock enable. Thus any path that is between elements driven by that enable is a multi-cycle path. It's nice and easy to specify these paths in a UCF file.

That could be very useful. I guess there's a lot of designs, my own included, that have multi-cycle paths that aren't constrained as such because they meet the timing anyway. Perhaps PAR times could be reduced significantly if a tool could pick out these paths. Cheers, Syms.