Another metastability mistake

So I was analyzing my design today and I happened upon another metastability mistake. I built this circuit:

I wanted to synchronize an external signal, but only when enabled. There was a good reason to do this, but I didn't want to risk metastability. I figured that the second flop solved the issue. What I didn't take into account was the feedback path of the first flop when the enable was low. It was theoretically possible that the first flop would oscillate metastable, even if only for l additional clock. Under most conditions you would assume that a single mux would be minor when compared to the full period of the clock and therefore it wouldn't be a problem. But it's not just an additional mux, it is also two wire paths instead of 1. That means that layout tools with a max wire path distance would now be doubled as there is a path from the q to the mux input, and from the mux output to the d. A nice solution was replacing the mux and enable with a clock gate enabled by the enable. At least this way you don't have to worry about the feedback path.
Be sure to balance the clocks!

The dangers of asynchronous design...

I have been pushing my own limits in some of my most recent designs. I have been synchronizing less, and I have been building delay dependent logic. This is interesting and challenging at the same time. Building logic that is low-power, efficient, and high speed is not so simple. Here is an example of mistake I caught myself making:

The second ff was gonna be metastable. And the output from the second ff was gonna be synchronized externally. I didn't care what value the second ff got, just that the third ff and the external synchronization flops  would get the same value. What I had forgotten to take into account was how metastability works. I forgot that the second ff can go high during metastability even though it may start and settle low.

 Luckily I caught this soon after I wrote it.