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.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.