[tbrownaw]

Async adds a lot of overhead to propagate readiness information alongside every data path and calculate it through every piece of logic.

Unless things have changed drastically in the last decade-and-a-half (well, or the professor in that class was wrong), it's way more efficient to just precompute all that and mess with shifting logic between pipeline stages so everything lines up as closely as possible against a shared click signal.

[keikobadthebad]

"Way more efficient" as a conceptual and implementation model.

But synchronous logic always leaves some speed on the table, since you have to choose the global clock rate for the longest data path that must complete in one clock; for any given path that may be active on a clock, it's likely to not be the longest.

In practice it's possible to architect synchronous critical paths with pipelining to keep the worst single-clock data path reasonable, basically spread the work over multiple clock periods so you can select a faster clock rate and so reduce the wasted time on average to the point nobody cares.

OP sounds like he stands zero chance of implementing any nontrivial async design if he's talking about 'flowchart' rtl generation in the same breath.

[thesz]

You forgot that clock delay is computed for worst-case register and combinational logic behavior, e.g., "99.9999% of all registers need this amount of time for signal to be stable before write", "99.9999% of this gate in real silicon will have this delay".

The chart I saw several years ago put about half of typical clock cycle delay into this "reserve time" part. I guess things did not change much since then.

[keikobadthebad]

It depends what you are doing but with async it's possible to synthesize SR latches that don't have these setup / hold and metastability problems, the output of the logic is directly strobes that set or reset the storage element.