Forum Discussion

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

TimeQuest Asynchronous Interface Constraints

Hi,

I have been through a lot of online material with nothing that seems to shed light on my query (or I'm just not getting it.)

I have a CPLD design I want to constrain properly using the TimeQuest analyser. All literature suggests that all input and output ports should be constrained. I have seen a lot of examples that derive these constraints (min/ max delays etc) using the datasheets and board delays of attached external devices driven by the same clock.

Nothing seems to mention how this is done with a purely asynchronous interface - example: a signal that may or may not be clocked that is simply sampled by the CPLD, and with respect to the clock feeding the CPLD this signal may change at any time.

Of course such a signal is double flopped to decrease chances of metastability, but what of constraints? Should such ports be declared with 100% clock uncertainty?

These are asynchronous signals feeding the synchronous ports of registers in the design. I mention this as any search of 'asynchronous port' results in recovery/ removal analysis documentation for signals feeding the asynchronous ports of a flip flop.

Any information or links to relevant documentation would be appreciated.

Thank you.

5 Replies

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

    Asynchronous signals that are input to the FPGA feeding synchronizers are typically constrained with false path statements in SDC. Less commonly, one could constrain them with set_multicycle_path constraints instead. If you were coming from the Xilinx world and are used to their methodology, then you could use set_max_delay constraints between the rising edge of the clocks. As I said though, most people cut the path with set_false_path statements. If you are concerned about the metastability issue, this can also be analyzed in Quartus II software.

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

    Note that the set_false_path is saying, "Don't analyze this path." So you're putting a constraint on the port that says not to constrain it. From a design perspective, having no constraint or telling Quartus not to analyze it is the same thing. From the perspective of completeness, having the constraint says that you've analyzed the signal and actively determined that it doesn't need a constriant. When you get handed a design someone else worked on(or when someone else gets this design someday) this is they type of thing you'll appreciate.

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

    Thanks for that link Pancake, it's quite an in depth PDF which I've just read. Like most of the other documentation I've read it doesn't really say that pure asynchronous signals entering a chip should be set as false paths, (assuming they are handled properly by the designer -double/ triple flopping).

    It does make sense that they should, it's just you don't want to cut timing from the analysis without some kind of confirmation that's how it's done.

    Thanks for the feedback.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    i probably read into the example set_false_path on the reset_button port to mean completely asynchronous

    anyhow Rysc is the guy to thank