DCFIFO: shoud i set flase path timing

I believe there are some recommended timing constraints to use with dcfifo's that might help, see:

page 20 of ug_fifo.pdf "Embedded constraint settings"

--- Quote Start ---

I believe there are some recommended timing constraints to use with dcfifo's that might help, see:

page 20 of ug_fifo.pdf "Embedded constraint settings"

--- Quote End ---

Hi,

thank for the answer.

i already look into that, and the document is unclear.

first it has this:

"When using the Quartus Prime TimeQuest timing analyzer with a design that contains a DCFIFO blockapply the following false paths to avoid timing failures in the synchronization registers"

then after few line we have that:

"The false path assignments are automatically added through the HDL-embedded Synopsis designconstraint (SDC) commands when you compile your design. The related message is shown under theTimeQuest timing analyzer report"

it saying that it adding it using an "HDL-embedded" SDC ...:confused:

any ways, i added those and i still have timing issues.

the question remains:

Do i add a "false path" between those clocks? :confused:

the false path in the documents refer to something else:

• For paths crossing from the write into the read domain, apply a false path assignment between the

delayed_wrptr_g and rs_dgwp registers:

set_false_path -from [get_registers {*dcfifo*delayed_wrptr_g[*]}] -to [get_registers

{*dcfifo*rs_dgwp*}]

• For paths crossing from the read into the write domain, apply a false path assignment between the

rdptr_g and ws_dgrp registers:

set_false_path -from [get_registers {*dcfifo*rdptr_g[*]}] -to [get_registers

{*dcfifo*ws_dgrp*}]

im asking if i need to false path between clocks .....

There are two ways forward,

If your clock domains are completely asynchronous then you could use a set_clock_groups command to completely cut timing between the domains. The downside is that it might cut paths that you didnt realise were being made in your design.

Or you can manually false path the clock crossing paths. This is more time consuming but you could avoid other issues by catching all the paths crossing the domain.

Also you can check the SDCs that are used in the design through timequest using report sdc

Hi,

thanks for all your comments.

so just to be sure, its ok to write on the SDC file :

set_false_path -from [get_clocks {clka}] -to [get_clocks {clkb}]

set_false_path -from [get_clocks {clkb}] -to [get_clocks {clka}]

when i have a dcfifo crossing the clock domain?

Hi,

I'm also using dc_fifo for synchronizing data between different clock domains. So I set that clocks exclusive in timequest:

set_clock_groups -asynchronous -group {clk_a} -group {clk_b}

No timing violations occur.

Jens

thanks,

it seems to work.

Q:

does the DCFIFO guarantees 100% error free data trasnfer from one domain to the other?

yes, but you have to take care about the fill level. Do not write to a full Fifo and not read from an empty Fifo. I'm using wrusedw and rdusedw for checking that.

Jens