help needed: passing toggle signals cross clock domain

[Altera_Forum]

Hi all...I have a process running at clock A (2.667MHz) which will generate a toggle signal X and I need this signal to pass to clock domain B (80MHz) which a FSM is updating its state according to this X...Time Quest is always giving me critical warnings saying that I have setup time voilation. I checked it out, it's all cross clock domain signals.. 

 so question: how do I effectively pass my toggle switch signal? I found something in "The Ten Commandments of Excellent Design-VHDL Code Examples"..but don't quite understand how to do it...any suggestion/advice?   Thanks

[Altera_Forum]

Hi, 

 You need to register the toggle signal through a cascade of two registers clocked by the 80MHz then use it in the FSM.   Other alternatives include having 80MHz only and generating clock enable at 2.66MHz(using modulo adder that increments by 266 and overflows at 8000 then use the oveflow pulse as clock enable).   example of two stage cascade:   process(reset, clk_80) if(reset = '1')then toggle_1d <= '0'; toggle_2d <= '0' elsif(rising_edge(clk_80))then toggle_1d <= toggle; toggle_2d <= toggle_1d; end if; end process;   then use toggle_2d as your FSM signal.   You may still get warnings but you may ignore them.   Kaz

[Altera_Forum]

--- Quote Start ---  Hi all...I have a process running at clock A (2.667MHz) which will generate a toggle signal X and I need this signal to pass to clock domain B (80MHz) which a FSM is updating its state according to this X...Time Quest is always giving me critical warnings saying that I have setup time voilation. I checked it out, it's all cross clock domain signals..   so question: how do I effectively pass my toggle switch signal? I found something in "The Ten Commandments of Excellent Design-VHDL Code Examples"..but don't quite understand how to do it...any suggestion/advice?   Thanks  --- Quote End ---     Hi,  the problem is that your two clocks are total asynchronously. That means that the phase between the clock edge is not fixed. Therefore the reported timing violations, but you can cut the pathes in the timing analysis. You have to design a clock domain crossing here. You are sending a single bit signal from a lower clock domain to a faster clock domain. So it should be sufficient to latch-in the signal with two FF running with the higher clock. I believe you can find a lot of stuff in this forum regarding clock domain crossing.

[Altera_Forum]

The cascade of two FF recommendation is considering the rare condition of metastable states, for most designs single FF synchronizers are sufficient to my opinion.  

 There may be however a problem with multibit signals (e. g. representing a number) which have to be transmitted coherently across the clock domain border. These signals need either gray encoding or you have to establish a handshake to avoid inconsistent results. Otherwise, if you have a 4-bit value changing from 0x7 to 0x8, it may be read also as 0x0 or 0xf due to delay skew.

[Altera_Forum]

Hi, 

 The whole idea here is to absorb the metastability itself. Thats what tsetup or TH violation is all about. The recommended number of stages is two minimum(look how dual clk fifos are designed internally).  I have never heard of one stage.   The issue of multibits and tackling it with grey coding doesn't make sense to me. Can you please explain that?   Regards Kaz

[Altera_Forum]

--- Quote Start ---  I have never heard of one stage.  --- Quote End ---   I guess, you have seen a lot of single FF synchronizers in cases, where metastability hasn't been discussed explicitely. Most synchronous edge detector design examples I've seen are using a single stage synchronizer for unrelated input signals. On the other hand, a two stage synchronizer strictly speaking doesn't remove or absorb metastabilities at the output, but further reduces their likelihood.   The necessity of using two or even more stages for a synchronizers depends on the consequences of metastable states for a design. If it triggers an unsafe FSM, that can get stuck forever in an illegal state after a single event, it may be necessary.    --- Quote Start ---  The issue of multibits and tackling it with grey coding doesn't make sense to me.  --- Quote End ---   It can be found e.g. in FIFO designs. There you have the problem, to transmit the pointer values (multibit entities) consistently between the two clock domains. You can study, how Altera Megafunction altsyncram_fifo solve this through gray encoding.

[Altera_Forum]

Can I use the same strategy if I have parallel data to be passed from one clock domain to the other? 

thx      --- Quote Start ---  Hi,   You need to register the toggle signal through a cascade of two registers clocked by the 80MHz then use it in the FSM.   Other alternatives include having 80MHz only and generating clock enable at 2.66MHz(using modulo adder that increments by 266 and overflows at 8000 then use the oveflow pulse as clock enable).   example of two stage cascade:   process(reset, clk_80) if(reset = '1')then toggle_1d <= '0'; toggle_2d <= '0' elsif(rising_edge(clk_80))then toggle_1d <= toggle; toggle_2d <= toggle_1d; end if; end process;   then use toggle_2d as your FSM signal.   You may still get warnings but you may ignore them.   Kaz  --- Quote End ---  

[Altera_Forum]

--- Quote Start ---  Can I use the same strategy if I have parallel data to be passed from one clock domain to the other? thx  --- Quote End ---     Hi,  for parallel data you should follow FvM's recommendations.

[Altera_Forum]

--- Quote Start ---  You may still get warnings but you may ignore them.  --- Quote End ---      --- Quote Start ---  ... but you can cut the pathes in the timing analysis.  --- Quote End ---    Rather than ignore reported timing violations, you really should cut the asynchronous paths once you have implemented the clock-domain crossing properly as suggested in other posts. If you don't cut these paths, the Fitter will needlessly try to optimize them, and cutting them makes your intention clear to someone maintaining the design.  If all paths between two clock domains are asynchronous in both directions (or if only one direction exists), you may use set_clock_groups.  If all cross-domain paths are asynchronous from clock A to clock B but not in the other direction (unlikely), you can use set_false_path from clock A to clock B.  If you need to cut individual paths because there are some synchronous paths between the same clock domains (also unlikely), use set_false_path for that.  Using set_clock_groups or set_false_path with the clock names is more efficient for TimeQuest to process than set_false_path for individual paths. For this particular design, you probably won't notice any difference in TimeQuest processing time or memory usage between doing it at the clock level or at the level of the individual paths, but get in the habit of using clock-to-clock exceptions like set_false_path, set_multicycle_path, and set_clock_groups when the design allows doing it at the clock level.

[Altera_Forum]

The best method to synchronize parallel (multibit) data depends on the nature of the data. 

The discussed gray encoding is only applicable to counter values that are known to change by one increment up- or downwards. In the general case, a handshake is needed:  After making the data available at domain A, set a DataReady flag. Latch the data at domain B and set a DataAck flag. At Domain A reset the DataReady flag on DataAck. At Domain B reset the DataAck flag on reset of DataReady. Now both sides are ready for a new transfer.

[Altera_Forum]

Hi all, 

 I rather suggest the following practical solution before "zhangyi17" loses hope:   just use a dual clock fifo of enough width and few words depth. That will take care of it. I am sure there would plenty of memory to spare.   kaz