Forum Discussion

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

TimeQuest/SDC: How Do I Constrain Synchronizing Registers Between Async Clock Domains

Hi

I have several async clock domains, and and passing control signals between them, using a 3-register pipeline to synchronise to the latch clock in each case.

TimeQuest reports timing errors to the first of each register in the pipeline, which I have gotten around by using false path statements, since that is what Altera seems to do with their MegaWizard FIFOs. I'm not sure if this brute force method is the right approach - is there a better way?

Thanks,

Chris

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi

    I have several async clock domains, and and passing control signals between them, using a 3-register pipeline to synchronise to the latch clock in each case.

    TimeQuest reports timing errors to the first of each register in the pipeline, which I have gotten around by using false path statements, since that is what Altera seems to do with their MegaWizard FIFOs. I'm not sure if this brute force method is the right approach - is there a better way?

    Thanks,

    Chris

    --- Quote End ---

    Hi Chris,

    using the false paths assignment is the right way to handle async clocks, but you have to model the clock domain crossings carefully. You could not specify any setup and hold relation in case you have total async clocks. All phases between the clocks are possible.

    Kind regards

    GPK
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi Chris,

    using the false paths assignment is the right way to handle async clocks, but you have to model the clock domain crossings carefully. You could not specify any setup and hold relation in case you have total async clocks. All phases between the clocks are possible.

    Kind regards

    GPK

    --- Quote End ---

    Thanks for the response. What do you mean by "model the clock domain crossings"? Is something required beyond the false path specification?

    I have 3 types of async relationship:

    1) Different frequencies (266 and 200 MHz; and 266 and 400 MHz).

    2) The same frequency (400 MHz), though derived from different ocillators, with an unknown phase relationship.

    3) Two clocks with identical frequencies (200 MHz), derived from the same oscillator. The phase relationship range can be calculated, but is large enough that synchronisation to prevent metastability will be required - data will not be safely within the destination register's setup and hold times.

    Does Altera have any documentation on constraining synchronizing registers across async domains?

    Thanks,

    Chris
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Thanks for the response. What do you mean by "model the clock domain crossings"? Is something required beyond the false path specification?

    I have 3 types of async relationship:

    1) Different frequencies (266 and 200 MHz; and 266 and 400 MHz).

    2) The same frequency (400 MHz), though derived from different ocillators, with an unknown phase relationship.

    3) Two clocks with identical frequencies (200 MHz), derived from the same oscillator. The phase relationship range can be calculated, but is large enough that synchronisation to prevent metastability will be required - data will not be safely within the destination register's setup and hold times.

    Does Altera have any documentation on constraining synchronizing registers across async domains?

    Thanks,

    Chris

    --- Quote End ---

    Hi Chris,

    have a look to this link: http://www.fpga4fun.com/crossclockdomain.html

    There you find a good description of how to deal with clockdomain crossings.

    Kind regards

    GPK
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi GPK

    Thanks for the link. This is what I'm already doing, though their short pulse capture technique is an elegant idea.

    However, what I'm looking for is documentation on the use of clock domain crossing sdc constraints, i.e. is anything required beyond specifying a node-to-node false path exception to the synchronizing register?

    Thanks,

    Chris

    --- Quote Start ---

    Hi Chris,

    have a look to this link: http://www.fpga4fun.com/crossclockdomain.html

    There you find a good description of how to deal with clockdomain crossings.

    Kind regards

    GPK

    --- Quote End ---

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hi GPK

    Thanks for the link. This is what I'm already doing, though their short pulse capture technique is an elegant idea.

    However, what I'm looking for is documentation on the use of clock domain crossing sdc constraints, i.e. is anything required beyond specifying a node-to-node false path exception to the synchronizing register?

    Thanks,

    Chris

    --- Quote End ---

    Hi Chris,

    you only need to cut all the paths with the false path setting.

    Kind regards

    GPK
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Using a "set_clock_groups -asynchronous" constraint may be a better idea. It cuts all paths between specified clock domains. It will also help the fitter in routing the design.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi all,

    I've been using the "set_clock_groups -exclusive" to cut the asynchronous paths. Is there a difference with the "-asynchronous" suggestion?

    Thx
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    -asynchronous and -exclusive have the same effect, see "SDC and TimeQuest API Reference Manual"