flancter and timequest

[Altera_Forum]

Dear All, 

i'm using classical implementation of flancter to realize signalling between multiple clock domains (see down). Now, this design is proven to be hazard free, however timequest of course realizes, that e.g. SetFlopxS is driven by both clock domains. Is it OK to set the false path to this in the timequest?  thanks  d.    --! @brief implementation of flancter as shown in app note by B. Weinstein entity flancter is  port (  ResetxRNA : in std_logic; --! reset signal  ClkSetxC : in std_logic; --! clock for setting signal domain  SetxS : in std_logic; --! set signal in ClkSetxC domain  ClkResetxC : in std_logic; --! clock for resetting signal domain  ResetxS : in std_logic; --! reset signal in ClkResetxC clock domain  QxM : out std_logic); --! output data end flancter;   --! @brief implementation of flancter architecture flancter of flancter is  signal SetFlopxS : std_logic;--! setting flop signal  signal RstFlopxS : std_logic;--! resetting flop signal begin  set_proc : process(ResetxRNA, ClkSetxC)  begin  if ResetxRNA = '0' then  SetFlopxS <= '0';  elsif rising_edge(ClkSetxC) then  if SetxS = '1' then  SetFlopxS <= not RstFlopxS;  end if;  end if;  end process;   reset_proc : process(ResetxRNA, ClkResetxC)  begin  if ResetxRNA = '0' then  RstFlopxS <= '0';  elsif rising_edge(ClkResetxC) then  if ResetxS = '1' then  RstFlopxS <= SetFlopxS;  end if;  end if;  end process;   QxM <= SetFlopxS xor RstFlopxS;   end flancter;

[Altera_Forum]

I'd never heard of the flancter ... 

 http://www.doulos.com/knowhow/fpga/fastcounter/ http://www.floobydust.com/flancter/flancter_app_note.pdf  Personally I have never needed to use this circuit.  I use two types of synchronizers;  1) the classic cascade of D-flip-flops, and  2) a toggle synchronizer, where the edges of the signal to be synchronized to are used as the clock to a DFF, and that DFF is configured as a toggle register. This is useful for synchronizing to signals that have short pulses, but a low duty cycle. Any pulse on the input will be converted to a slower toggling signal. The toggle signal passes through a classic synchronizer, and then an edge detector.  What are you trying to synchronize?  And yes, for TimeQuest, you will have to set false paths, or perhaps create an 'asynchronous' clock group for the two clock signals involved.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

sorry for late response.  In fact, I'm not trying to synchronize events, but rather generate a signal which is set in one domain, and reset in another domain. The application I have is, that I have to reset an external circuit, which is driven in different clock domain than FPGA. However the reset must asserted for an unknown time, for as long as another (input) signal from the circuit tells me, that reset was performed.   So I though that by using flancter I can set up the reset signal in my domain (120MHz), and when chip announces in its 40MHz clock domain that it finished, I use this signal in flancter to 'null' the reset signal.  I know that this could be probably realized by using two-ff at the input of the chip and resync this 40MHz signal into 120MHz and doing edge detection. But I thought that those two methods could be identical in what I need to do and save some registers. (I have plenty of them so no really need do to some economy here :)  I did not know however, that you need to use two-stage syncing as well for the signal coming from external chip. This information I got from the doulos link you sent earlier.  d.

[Altera_Forum]

Additional question to this: 

 if you have an entity, which you use to realize the cascade of two flip-flops. Say this entity is called many_ff,  and you use this entity in the design whenever you need to synchronize two clock domain signals,  is there any 'generic rule' for the timequest analyzer to say that whatever is on the input of this entity is false path to whatever is at the output of this entity? So far for each such instance of the entity I try to identify the signals there (in the timequest wizard) and generate single false path rule for this specific instance. Would be nice however if I could say only that many_ff is synchronizer and hence false path.....  thanks d.

[Altera_Forum]

--- Quote Start ---   is there any 'generic rule' for the timequest analyzer to say that whatever is on the input of this entity is false path to whatever is at the output of this entity?  --- Quote End ---    In the case of two clock domains, you just tell TimeQuest they are separate via:  set_clock_groups -exclusive -group clk_A -group clk_B  And TimeQuest will set false paths for you.  Cheers, Dave

[Altera_Forum]

Isn't that somewhat dangerous? afaik this command will completely ignore all the relation between these clocks. So if you have forgotten somewhere a synchronization circuit between these two domains, timequest will not complain. is this correct? 

 d.     --- Quote Start ---  In the case of two clock domains, you just tell TimeQuest they are separate via:  set_clock_groups -exclusive -group clk_A -group clk_B  And TimeQuest will set false paths for you.  Cheers, Dave  --- Quote End ---  

[Altera_Forum]

--- Quote Start ---  Isn't that somewhat dangerous? afaik this command will completely ignore all the relation between these clocks. So if you have forgotten somewhere a synchronization circuit between these two domains, timequest will not complain. is this correct?   --- Quote End ---    Yep :)  Buyer beware, your mileage may vary, etc.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Isn't that somewhat dangerous? afaik this command will completely ignore all the relation between these clocks. So if you have forgotten somewhere a synchronization circuit between these two domains, timequest will not complain. is this correct?  --- Quote End ---   You can enable the 'Design Doctor' it will warn you ...

[Altera_Forum]

Dejfson: where did you get the idea that flancter "...design is proven to be hazard free..."? On the contrary, it was designed by a person who apparently has no clue about synchronisation. You have to constrain the propagation paths between the FF to make it work, I'm not even sure if the timequest would allow you to do that. You'll be much safer with just passing a signal (state transition) to an edge detection circuit.

[Altera_Forum]

dejfson, 

I agree with Dave. - Assuming your signal comming from the 40 MHz domain is assured to last at least one 120 MHz cycle, using a cascade of DFF is, by far, the correct option. - If not, using the toggle scheme and then the DFF cascade.  Regarding constrains,  Let's say r1 operate with clk1, and r2 and r3 operate with clk2.  set_false_path -from [get_pins r1|q] set_false_path -to [get_pins r2|d] ...  In your case, since it's external set_false_path -from [get_ports your_pin]