In essence what makes a signal or even Asynchronous in a digital design

[Altera_Forum]

I understand that something that does not occur in line with a clock (its edge that is) becomes asynchronous. I wish to know if there is something I need to add to it, or if there are some exceptional or anomalous cases. 

 So are the outputs of the combinatorial blocks asynchronous? Since they outputs of flip-flops need time to change after the clock edge, does that make them asynchronous? If another signal occurs periodically but with a lower frequency than the clock edge but in line with it, does that make it asynchronous as well? And finally what if there is a phase difference between clk and a signal, they both have same frequency but the signal has a phase difference with respect to clock - would this make it asynchronous as well?  People talk of phase difference and as far as I can see it, it makes sense with periodic signals only, and since a phase delay looks like a time delay, I am sure that expressing it as a fraction of time makes more sense?

[Altera_Forum]

For combinatorial blocks, if the inputs are all driven by the same clock, the output will be timed by timequest (in Quartus) and can be considered synchronous. For most cases, if you are using signals on two different clock domains, the output is asynchronous to any clock and needs to be synchronized appropriately. 

 Flip-flops can normally be considered synchronous in your design. Timequest handles the time delay associated with flip-flops.  If you have a signal locked to the same clock, but in a different phase, I do not consider that to be asynchronous. The care you must take is the setup and hold times with respect to the rising (or falling) edge in your design.  I'm sure others can give a better explanation on asynchronous vs synchronous, I figured I'd give it a go.

[Altera_Forum]

The reason I asked this question even though it appears too simple, is to clarify the real vs ideal (simulation) world. We can make neat timing diagrams and show how neat all signal transmissions are, but in reality there are skews and slacks and jitters and propagation delays. Thus things don't happen *at* the clock edge, but somewhere around it.

[Altera_Forum]

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.

[Altera_Forum]

A signal generated on a clock edge is synchronised to that clock. It will never be nicely following it as rtl simulation models it but will follow the edge by reg tCO plus routing delay . If then static timing is happy then that delay will be absorbed within one clock period such that next edge will sample the change. All the combinatorial clouds between registers are assumed generated by source register on its clock. Any offchip signal or signals from a different clock domain joining the cloud are asynchronous unless clocks are related. 

 Thus it is true that a clean rtl functional model plus passing timing is good indicator of actual hardware model success. One of the main pitfalls here is multicycle de-constraints and false paths since rtl model is not aware of them yet timing model is. If you are not sure about your deconstraints then you better do timing simulation model. With these deconstraints, the actual delay inserted may exceed one clock period.