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.
Blog Doing Math in FPGAs Tom Burke 14 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...