The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty un

The metastability in clock domains is a complex subject (it is a named problem with a finite number of solutions), and you were warned people have difficulty understanding why it is a challenge. A toy example: 1. set flag foo=1 2. check flag bar=1 3. set flag foo=0 4. check flag bar=0 These events happen in a sub-optimal repeatable order on non-optimized gcc C, and with precise predictable/verifiable op timing. We will assume interrupts are disabled in critical sections, and register states are repeatable prior to execution. Yet, the same "bar" may have undefined behavior in llvm given the flag states look unrelated to the compiler, order/operations may not be preserved when abstracted, and linear-timing is now a compile-time packed op specific random ordered implementation. Thus, event times may happen before the parallel state has actually occurred. Perhaps I am not the right person to explain this subject, but would recommend looking at the zynq FPGA Linux kernel example DMA module structure for more details. It should demonstrate how to coordinate parallel things better using 1 or more of the known metastability issue workarounds, and the constraints of state propagation across complex logic fabric. In some use-cases repeatability is more important than performance/assumptions-of-safety. There is a clear difference between Application space and RT space. This is as far as I can guide folks on the subject, and if one has never encountered these issues... than don't worry about it... Best of luck, =3