Forum Discussion

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

How to synchronize reset signal without using synthronizers , through quartus setting

Hi All,

I have a reset pin (which is not the system reset but reset to few registers) in my design which i know will be synchronized in a wrapper file.

But in my top since its not synchronized (in the RTL) so it is failing recovery and hence i am not able to constrain my design as a whole as quartus does takes recovery analysis during P&R.

Is there any switch in quartus which can tell the tool that the reset is synchronized and thus can temporarily pass recovery analysis and i can move on with the design.

I just want the constraining to be proper such that my P&R is at the optimum level.

4 Replies

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

    It's not a Quartus level switch, but a set_false_path in your .sdc that does this:

    set_false_path -to [get_keepers {synchronized_register}]

    (You could do it -from the reset pin, or use both -from and -to to be more exact).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ok thank you RYSC for your quick reply.

    I have this constraint as

    set_false_path -from [get_ports {mgmt_reset}]

    And even then i have failing recovery paths, however when i assign a virtual pin to this port the design passes recovery analysis.

    But i am not sure whether such a work around is acceptable or not.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    TimeQuest tries to analyze everything, and with the tightest relationships it can find. This is the safest approach since it doesn't know how the design actually works. If you design something that can be asynchronous, then you add a set_false_path to tell TimeQuest that. If you design something that can occur over several clock cycles, then a set_multicycle_path is applied to tell TimeQuest that. These are called exceptions, and are the way to tell TQ how your design works, at least from a timing analysis perspective. So it is acceptable, and not really a work-around but the recommended flow.

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

    Ok now i get you.

    Thanks a lot once again to share your experience.