Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

flancter and timequest

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;

9 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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]