# Fpga Crossing signals between related clock domains

I have an fpga design with two clocks, one is 54MHz and the other is a divide-by-4 clock of the 54MHz, this is 13.5MHz clock.

The 13.5MHz clock is generated by dividing the 54MHz clock in vhdl, and feeding it through an internal clock buffer with high fan out. The fpga I work on don't have PLLs.

Do I have to worry about metastability when signals are crossing the related clock domains?

• No, you just need to check if your synthesis tool or static timing analyzer (STA) recognized the related clock. Otherwise, you need to inform STA by setting a proper timing constraint for related clocks. – Paebbels Jun 27 '15 at 7:12
• Does you $\div 4$ clock require 50% duty cycle? If it is only used internally, then what you can do is rather than dividing the clock, everything uses 54MHz and you generate a clock enable (which is high for 1 cycle in 4) for any register which runs at 13.5MHz. – Tom Carpenter Jun 27 '15 at 8:29
• I have tried that, but have run into some trouble, because a lot of the logic, math calculations, takes longer than the 54MHz period, which is ok. But the analyzer creates timing violations, it expects the output to be ready in the next 54MHz period, I previously tried to solve that using multicycle timing constraints on the related signals, but I have a very hard time actually verifying that those constraints does only cover the correct signals. – JakobJ Jun 27 '15 at 8:43
• The idea to run everything off the 54MHz is a good one. If the math calculations take longer than one clock period then you should find a way to split up the calculations into a pipelined manner so that it takes two or three clock times to complete. The intermediate results at each of the pipeline stages need to be registered at the 54MHz clock. – Michael Karas Jun 27 '15 at 13:37
• Because you eliminate the need for any clock crossing issues. Almost every seasoned FPGA or ASIC designer will tell you this. Same clock everywhere also allows for far easier pipelining logic. --- So consider that if you need somethings to happen at 1MHz all that logic is driven using clock enables that are a divide by 54 from the main clock. It the 1MHz loc needs several stages of pipelining then the /54 clock enable is simply run through the equivalent of a short shift register to produce as many delayed phases as needed. – Michael Karas Jun 27 '15 at 15:40

## 1 Answer

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.