Forum Discussion

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

recovery issue

Hi all!

I use an Altera DCFIFO with the option "resynchronize aclr in wr_clk domain".

Until today, aclr port of my DCFIFO was directly connected to a pin of my device.

Today, I changed this and used an internal signal (a register in rd_clk domain) for aclr port.

Now I get recovery errors on 2 registers in the DCFIFO:

--- Quote Start ---

dcfifo_inst|auto_generated|wraclr|dffe15a

--- Quote End ---

and

--- Quote Start ---

dcfifo_inst|auto_generated|wraclr|dffe16a

--- Quote End ---

It turns out these are the 2 registers used for resynchronization of clr in wr_clk domain. So there is no recovery issue and I could get rid of the error messages with

--- Quote Start ---

set_false_path -to [get_cell_info -name [get_node_info -cell [get_nodes *|auto_generated|wraclr|dffe15a[0]|clrn]]]

set_false_path -to [get_cell_info -name [get_node_info -cell [get_nodes *|auto_generated|wraclr|dffe16a[0]|clrn]]]

--- Quote End ---

as advised in several posts I could read on the web.

My question is:

Why didn't I get these errors when aclr was connected to a pin of the device?

Because we have no warranty of any kind about the timing of signals from this pin, so...

Julien

3 Replies

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

    --- Quote Start ---

    Why didn't I get these errors when aclr was connected to a pin of the device?

    Because we have no warranty of any kind about the timing of signals from this pin, so...

    --- Quote End ---

    The Quartus II compiler just assumes that you know what you are doing if you connect a physical FPGA pin directly to a function. Unless you tell Quartus that it is asynchronous (by setting a false path) it assumes that is well behaved and respects the actual Tsu and Th requirements as posted in the Datasheet Report section in TimeQuest.

    BTW you can also set a false path for the input pin only e.g.
    set_false_path -from Reset_pin -to *
    so you don't have to look up all those names. And imho is better and more appropiate. TimeQuest (and the Fitter) will properly constrain the 2-register anti-metastability chain.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    You're right. Until you put a set_input_delay constraint on the I/O, TimeQuest doesn't know how to time the circuit, so you wouldn't get any timing failures. It would show up under Unconstrained Paths though