cdcclockfpgavhdl
I have been designing a few projects on different FPGA's in VHDL, and it seems my most common source of "hard to find errors" is when I forget to synchronize an async signal, or forgets to resync a signal crossing clock domains.
My best weapon so far, has been to draw block schematic of the components.
So my questions is, what is the best design practice to prevent these errors?
If the throughput of data transfers is low then you can use a simple handshake to perform the clock domain crossing:
Your launch side places the data in a register and inverts a single bit flag. The flag is synchronised into your latch clock domain and the inversion is detected indicating that there is new data to be re-registered into the latch clock domain.
The latch clock domain inverts another acknowledge bit which is then synchronised back into the launch clock domain, informing the launch side that it can send another word of data.
You still have to take the necessary precautions on the single-bit synchroniser chain (at least 2 registers placed close together). You may also find that a greater number is required since the false path allows the fitter to physically place the two multi-bit registers far apart. You may need to use a delay constraint to limit the placement (set_max_delay on Altera or define_path_delay on Xilinx).
Obviously the rate at which you can transfer words is much less than using a dual clock FIFO. You say you have 'no more FIFOs' left but remember that both Altera and Xilinx support small FIFOs composed from special logic blocks (MLABs in Altera parlance or SLICEMs in Xilinx speak).
No, you don't have to worry about meta-stability, but you do need to make sure you constrain the clocks appropriately. Many modern FPGA Static Timing Analysis (STA) tools have commands to help constrain related clocks.
You didn't mention which vendor you're using. For the sake of example, the process for Altera would be to specify a clock constraint on the 54MHz source clock as your normally would, and then use "create_generated_clock" for the slower clock as shown below.
create_clock -name {clk} -period 18.518 [get_ports {clk}]
create_generated_clock -name {clk4} -source [get_ports {clk}] -divide-by 4 -master_clock {clk} [get_keepers {clk_div_4}]
Note that we did not specify the frequency for the slower clock. We only told the STA tool that it is the frequency of the source clock divided by 4. If you follow this approach the STA tool will properly account for the latencies of both the source and derived clocks.
To verify that things are working as you desire it's often helpful simply just to use the STA tool to report the timing between registers that cross the domain and see if the results match your expectations. Again, not sure which vendor you're using but you'll probably want to look for commands like "report clock transfers" or "report clock tree".
As for whether or not your approach is a good one vs running everything off the 54MHz, that depends on the details of your design and there is no one right answer. Either approach is acceptable in various situations. For example, if you run the entire design at the higher frequency then you don't have to worry with clock crossings, but your code may be significantly more complicated because of pipelining, or the use of multi-cycle paths. However, if it's a just a small portion of your design that you want to run on a slower clock then perhaps you'd be better off doing the extra work to pipeline it instead of dealing with the second clock domain.
Best Answer
Today even FPGA designs can have extremely complex clocking architectures and many async inputs, resulting in many potential CDC issues.
I'd say that the following points constitute a minimal set of "rules of thumb" for avoiding CDC bugs:
I'm sure that the above list of practices is incomplete, and can be easily extended.
I also suggest considering CDC verification tools (like Questa CDC from Mentor) - these tools use formal techniques to automatically detect CDC issues in your design.