Forum Discussion

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

Data synchronization issue

Hi,

I am facing an issue while synchronizing data between two clock domains.

clka is at 200Mhz, coming in to the FPGA (phase not known)

clkb is at 200Mhz 180 Phase shifted (generated from a PLL whose input clock is clka)

I know there are other ways to synchronize data but I used a fifo to sync a signal coming from clkb to clka. So I attached the wr side clock with clkb and read side clock with clka. Now the issue is, sometime data sent from clkb is not received at clka domain. I tried with a simple counter and I found that data is not being sync. This case happens once is a thousand clock cycles

I have no clue whats happening I guess that there can be a little jitter in clka (since its coming from outside fpga but that pll never gets unlocked) thats causing the issue.

Is there a way to remove jitter or varying delay between clocks? Or should I try something else to sync data between clocks

*FIFO sync stages are set to 3 so I guess there must be nothing wrong with the fifo

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    One possibility is that the clock crossing is OK and your bug lies somewhere else.

    Does your design meet timing constrains?

    Another possibility is that some of the logic in the dcfifo is running at the limits the FPGA is capable of.

    The transfer from clkb to clka only has 2.5 ns to work with.

    And when you generate a dcfifo with 2 or more stages, Quartus assumes the clocks are asynchronous and inserts a false path exception, so no timing analysis is performed on the transfer from clkb to clka.

    Since the two clocks have a know relative phase, then the timing in the clock crossing can be analyzed.

    You don't need to/shouldn't use asynchronous design techniques in this case. Try to simply use two registers: reg@clkb --> reg@clkA.

    TimeQuest will analyze the design and tell you if it's meeting constraints or not.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks for the reply rbugalho... But I don't understand what gets wrong if I used the dcfifo in this case...

    Also I used the signaltap with reference clock set at clka... I saw that the counter is perfectly at clkb (for example i generated 15 continues valids on clkb domain after certain period) but on the other side i.e. at clka domain I see sometimes 15 and sometime 14 and sometime 16 valids.... I also counted the valids using a counter on clka domain... In other words I am pretty sure that logic is correct but I am not sure about the synchronization or clock jitter... I also checked that there is no negative slack between clock domains.

    Please help... I am running out of time
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    As I said, with a dcfifo with two or more stages, a false path exception is inserted and timing is simply not analyzed.

    So, you won't get a slack report no mater what.

    Try to reduce it to a single stage dcfifo and see what you get in timing analysis.