Forum Discussion
That's one of the major benefits of synchronous design. Most people only do RTL simulations, which is in the ideal world. They then do static timing analysis, which accounts for skews, slacks, jitters, on-die variations, PVT variations, etc. and ensures that the design works in the real world. It's the combination of these two that makes the design work(or you have a timing failure, which is a blatant way of telling you where and why it won't work). One thing that often gets overlooked with static timing analysis is that each transfer covers a range. For example, if you have a 10ns clock driving two registers, the setup relationship is 10ns and the hold is 0ns. As long as the data transfers within that range, it matches the RTL simulation. But STA can do use different timing models to analyze the setup versus the hold. I'm not just talking about slow/fast timing models(and the other corners that have been added), but within a timing model there are sub-models to account for on-die variation, rise-fall variation, etc. All sorts of things to do worst case analysis and ensure the design passes the extremes.
Where all this falls apart is a) incorrect static timing analysis constraints, in which case you're just telling the tools the design behaves differently than it should and b) asynchronous logic, which can't be bound within a range and can't be properly analyzed to ensure it works under all conditions. I'm oversimplifying it(as asynchronous logic covers so many different things), but hopefully makes sense.