Forum Discussion

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

Sync and async clocks, fitter, ...

Hello everyone!

At first I'd like to mention that I'm pretty new to programmable logic so I don't know a lot of stuff that's probably obvious for PROs.

1)

So, for example, I'm using two clocks in my design. They can be synchronous or asynchronous (if I understand correctly what is meant with that):

*) sync case would be:

f1 |--------|________|--------|________|

f2 |--|__|--|__|--|__|--|__|--|__|--|__

*) async case would/could be smth like this:

f1 |--------|________|--------|________|

f2 _|--|__|--|__|--|__|--|__|--|__|--|__

meaning the clock edges doesn't match at any point.

If I know they are asynchronous then, when I constrain both clocks, I set them as async clocks with set_clock_groups command. So the question is, how the Fitter can work out any timing requirements from that? I mean, the phase shift is unknown.

2)

Same situation - using two clocks. First one directly from external oscillator, second one from PLL, which source clock is the same external oscillator. I don't know much about PLL's, but I have observed that the PLL's output clocks aren't sync with input clock (or at least might not be). So, am I right about that? And if yes, then is that phase shift random? Meaning, every time I restart the device, the phase shift can be different?

I'm asking this because I used two such clocks and had them constrained as asynchronous. After a full compilation there were no errors and TQ reported no timing violations. At first the design was working properly (on device), but later after adding more stuff to design it sort of 'broke down', meaning it didn't work properly, although still had no errors or violations reported. Then I just added a few more lines, recompiled, programmed and it worked again. And so a few more times. This started me thinking about what could possibly be wrong, and then I started thinking about async clocks and Fitter.

As I mentioned above I'm just a beginner, so any help/advice will be appreciated.

Thanks in advance,

4 Replies

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

    What you are ultimately talking about is crossing clock domains. When I design, I assume that all clocks are asynchronous to each other (unless the outputs are out of the same PLL). The fitter/timing analyzer will make moderate efforts to place registers crossing clock domains close together.

    There are a few things you should keep in mind when designing:

    1. Always register input signals (when possible) on the clock that you will be performing your work.

    2. When sending single bits of data (pulses/flags), be sure to register them at least once before using them in your new clock.

    3. Sending data buses can be a little tricky. Dual clock FIFOs are good at transferring data from one clock domain to another.

    I might suggest attempting to work in one clock domain (with clock enables if needed) for the majority of your design and switching only at the edges of your design.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    1) If you use set_clock_groups to say two clocks are asynchronous, then the fitter doesn't have timing requirements between them, since as you point out, the phase-shift is unknown.

    2) The PLL output and oscillator will not be edge aligned, but the difference will not be random, it will be the same compile to compile. Just as importanly, TimeQuest will calculate that difference, use it to drive the fitter to try and meet timing, and report whether it was successful or not.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Two clocks are synchronous if the relative position of their edges is known or can be calculated (with some uncertainty); they do not need to be edge aligned nor exact.

    If this condition is met, then the TimeQuest can and will analyze the timing of any path between those two clocks.

    If the relative position of the clocks' edges can't be determined, then the clocks are asynchronous.

    In that case, you need to use asynchronous clock domain crossing techniques to cross between the clock domains.

    And you need to use set_clock_groups/set_false_paths to tell TimeQuest not to try and analyse paths between those two clocks, as any analysis would be non-sense.

    Which brings us to why you don't get any timing violation reports: by setting the clocks as asynchronous, you told TimeQuest not to analyze those paths.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thanks guys for all the replies!

    You answered all my questions and more, that's very helpful!

    Cheers