fast clock signal to slow clock signal transfer - 2 questions regarding clock domains

[yuvalkesi]

Hi,
1. I have a signal which is generated in fast clock domain. I need to pass this signal to a slow clock domain.
I have an idea, I wanted to be sure this is the correct way to do it.
I thought about making this signal longer (using a state machine with the fast clock) and then deriving it (with 2 FF's using the slow clock) making a synchronizer, and then pass along the derived signal to the slow clock domain.
something like that:

process  (slow_clk, clr)  
begin         
    if clr = '1' then
		d1_rd <= '0';
		d2_rd <= '0';
		d3_rd <= '0';
	elsif rising_edge(slow_clk) then
		d1_rd <= long_rd; -- after SM to make it longer
		d2_rd <= d1_rd;
		d3_rd <= d2_rd; -- pass d3_rd to the slow clock domain
	end if;
end process;

Is this the correct way doing it or is there anothe more 'code' friendly way?

2. I have an address bus generated in fast clock domain, and I need to pass it along to a slow clock domain.
In order to avoid using complicated methods to derive a bus (using hand shake mechanism, etc.) I thought about generating an 'enable' signal in the fast clock domain, and then, using the method described above (in Q'1), passing the fast domain address bus to the slow domain BUT and only but the slow signal (like d3_rd) is generated.
Is this the correct way doing it or is there another more 'code' friendly way?

Thanks!

 

[jrwebsterco]

I don't think there is a significantly more "code friendly" way; instead I'd say that the "design principles" are more critical than the code, for what you are doing here.
I believe that you are on the right track, but a few comments ...

What you say in (1) seems correct, assuming that the lengthening of the "enable" (your long_rd from your FSM) accounts for the length of the slow clock-period.
(also, someone might argue you only need two stages of re-synchronization in the slow-clock domain, but three is better for mission-critical designs if you can handle the added latency)

What you write in (2) is worded a bit unclear, but I think you are saying that you would make sure that the address-bus changes some "safe" number of cycles prior to when the enable signal is asserted, and after enable is de-asserted.
This also seems correct, but note that after you've actually placed the design physically, you also must ensure that the routing/buffering-delays do not somehow differ to extremely to cause too much skew between all signals crossing the clock boundary, or perhaps too much clock-skew at the receiving flops.
(however, this is only a practical concern for very fast clocking and long-routing situations, where even the slow clock is quite fast and you also have large skewing issues)

You might want to take a look at this paper: http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk.pdf
It covers and reinforces design principles of what you are doing, specifically sections 8.1 and 9.3.

 

[yuvalkesi]

Hi,
Thank you for the response.
I found this link which talks also about my problem and the solution is the same as mine, just clarifies it more...
https://www.edaboard.com/threads/237211/

 

[zjwywn]

Q1. I think you didn't show us the length of the signal to be synchronized, this is important in choosing synchronization technique. Refer to
https://www.fpga4fun.com/CrossClockDomain.html
for detailed information.
Q2. If you are sure about when the address bus get stable , and the address bus changes slow compared to the slow clock domain, then using 'enable' signal will be useful. When sampling a 'enable' signal , you can capture the address bus without using the method described above (in Q'1).

- - - Updated - - -

In addition, bus signals can't be synchronized using method in Q1.

 

[lucbra]

by any means, if you are doing it this way, you'll lose a lot of samples.
Assuming that the fast clock is providing bursts of data, you can push them in a dual clock'ed FIFO at high speed, and pop at slow speed.

 

[mrflibble]

If you have bursts you can use a fifo as pointed out, as long as the average data rate is low enough to be able to handle it at the low clock side. And obviously the fifo has to be deep enough to handle the bursts. If you are sampling continuously you will either have to decimate it, or do some averaging at the fast clock side.