There is another issue with data coherency that you did not address. The trace delay for all bits in the "A" bus must be approximately the same, and should be less than the period of C2. Unfortunately, it is common to "false_path" the data from FA to FB, which allows the tools to violate this requirement.
This is especially a problem in the case where C1 and C2 are asynchronous clocks that are nearly the same frequency, and that frequency is fairly high. For example, with a frequency of 400MHz, the C2 period is just 2.5ns. If A is a 6-bit Gray coded value, and the the data delay for most bits of A ~0.5ns, while the delay for A is much larger (5.5ns, 2 full C2 clock cycles later), you can run into an issue where the receiver gets a Gray code sequence that can lead to problems:
001111 (bit 1 transitions)
001110 (bit 0 transitions)
001010 (bit 2 transitions)
001100 (bit 0 transition!)
001010 (bit 1 and 2 transition)
In this event, the Gray code that the receiver sees appears to have decremented (from 001101 to 001100), where it should have only incremented.
We have been able to address this problem in the Xilinx FPGA tool flow using a TIMESPEC with DATAPATHONLY, but have not been able to find a solution for this issue in the Altera FPGA tool flow.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.