+ Post New Thread
Results 1 to 6 of 6
  1. #1
    Member level 5
    Points: 1,762, Level: 9
    Achievements:
    7 years registered

    Join Date
    May 2009
    Posts
    92
    Helped
    0 / 0
    Points
    1,762
    Level
    9

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

    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:
    Code:
    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!

    •   AltAdvertisement

        
       

  2. #2
    Member level 4
    Points: 1,148, Level: 7

    Join Date
    Jul 2010
    Posts
    75
    Helped
    40 / 40
    Points
    1,148
    Level
    7

    Re: fast clock signal to slow clock signal transfer - 2 questions regarding clock dom

    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/paper...J_AsyncClk.pdf
    It covers and reinforces design principles of what you are doing, specifically sections 8.1 and 9.3.



    •   AltAdvertisement

        
       

  3. #3
    Member level 5
    Points: 1,762, Level: 9
    Achievements:
    7 years registered

    Join Date
    May 2009
    Posts
    92
    Helped
    0 / 0
    Points
    1,762
    Level
    9

    Re: fast clock signal to slow clock signal transfer - 2 questions regarding clock dom

    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/thread237211.html



    •   AltAdvertisement

        
       

  4. #4
    Newbie level 3
    Points: 171, Level: 2

    Join Date
    Oct 2012
    Posts
    3
    Helped
    0 / 0
    Points
    171
    Level
    2

    Re: fast clock signal to slow clock signal transfer - 2 questions regarding clock dom

    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
    http://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.



  5. #5
    Advanced Member level 2
    Points: 4,734, Level: 16

    Join Date
    Oct 2003
    Location
    Belgium
    Posts
    514
    Helped
    73 / 73
    Points
    4,734
    Level
    16

    Re: fast clock signal to slow clock signal transfer - 2 questions regarding clock dom

    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.



    •   AltAdvertisement

        
       

  6. #6
    Advanced Member level 5
    Points: 14,946, Level: 29
    mrflibble's Avatar
    Join Date
    Apr 2010
    Posts
    2,724
    Helped
    687 / 683
    Points
    14,946
    Level
    29

    Re: fast clock signal to slow clock signal transfer - 2 questions regarding clock dom

    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.



--[[ ]]--