cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
4,450 Views
Registered: ‎02-26-2014

PLL IC's asynchronous clock and MMCM's clock group

Jump to solution

Hi, Avrum:

   I have some doubt about the “asynchronous clock group” in Vivado user guide <UG903 - Vivado Design Suite User Guide-- Using Constraints> and look forward to your help in detail.

QQ截图20170602110501.png

Questions:

1) According to the above description, two clocks with different frequency Must be regard as “asynchronous clock group”. But if the two clocks with different frequency coming from the same oscillator or PLL IC, are they regard as “asynchronous clock group” or “synchronous clock group”? How will the Static timing analysis work?

 

2) If two clocks with Same frequency coming from the same oscillator, But without determinacy phase relation. Are they regard as “asynchronous clock group” or “synchronous clock group”? How will the Static timing analysis work?

 

3) If two clocks with Same frequency coming from the same oscillator or PLL IC, At the same time, there is determinacy phase relation between them. For example, 45 degree or 60 degree. Are they regard as “asynchronous clock group” or “synchronous clock group”? How will the Static timing analysis work?

 

 4) In Queston 2, Actually I make an assumption that there is the determinacy phase relation into the FPGA pins. Now Let us discuss more in detail. In fact, generally speaking, when I Use PLL IC’s output phasing adjustment, the two clocks’ determinacy phase relation refers to PLL IC’s output rather than the FPGA input pins. The trace delay between PLL IC’s output and FPGA input pins determines the actual phase relation in the FPGA input pins. But trace delay will vary with the PVT variation. So the phase relation is impossible to accurately describe. Is that right?

 

 5) In general ,we think the Static timing analysis will guarantee the setup time and hold time in FPGA fabric . But If Question 4 is right, what’s more worse is that: the delay and phase relation are hard to determine, so there is a risk to destroy the STA result. What to do?

 

       The following questions will turn to the FPGA’s MMCM/PLL’s Static timing analysis. Usually we use a MMCM to divider to several clks. The Xilinx tool will consider the all MMCM’s output clks as “synchronous clock group” and analyzes paths.

1) If there are two clks with same frequency coming from the same MMCM in FPGA, and there is determinacy phase relation between them. For example, 20 degree or 40 degree using CLOCK Wizard, but there is no path between them. Can I consider them as a particular “asynchronous clock group” with determinacy phase relation? Can you give an example using ISE and Vivado?

 

2) Continuing the above question 1), how will the Static timing analysis consider the case with no path but has determinacy phase relation? Will the STA analysis every MMCM’s output clk path independently?

 

3) If we will be Not Required phase relation between the two clks with the same frequency coming from the same MMCM, but the default set in Clock Wizard requires the output phase. If I don't fill in, the default value is 0 degree. What should I do to override the determinacy phase relation?

 

4) If there is Not Required phase relation, but the default set in Clock Wizard is 0 degree. At the same time, there is no override constraint in XDC or UCF. So I guess the Place tool will consider the two MMCM’s output clks coming from the same analyses start point. So it is obviously more difficult to route than two independent clks from FPGA pins. At the same time, a longer time will be required. Is that right?

 

5) Futhermore, can I consider “Not Required phase relation between the two clks with the same frequency coming from the same MMCM” as “asynchronous clock group”? Can you give an example using ISE and Vivado? What’s the difference between “Not Required phase relation” coming from the same MMCM and “Required phase relation” coming from the same MMCM?

 

6) Now let us focus the more general clk architecturesif there is no phase relation between the two clks coming from the same MMCM, there are two architectures:

    a) still use the MMCM in FPGA.

    b) replace the MMCM and use two outputs coming from the same PLL IC’s output.

    Obviously, there is no frequency shift no matter which method will be used. But there are some differences between them. Except the above described Question 4), can you give me more complement and Which one is your recommend and give your expiation in detail.

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
7,174 Views
Registered: ‎01-23-2009

1) As I know, the Xilinx tool ISE 14.7’s default set is to regard clks from different pins as asynchronous clock. So ISE will not analyze the path between them. However, if there are two clks coming from same PLL IC with determinacy phase relation. How to constraint them in UCF to tell ISE?

 

There is a special format for creating related clocks in UCF - you use the TIMESPEC name of the first one in the creation of the second one

 

NET "clk_pin_p" TNM_NET = clk_pin_p;
TIMESPEC TS_clk_pin = PERIOD "clk_pin_p" 5 ns HIGH 50%;

NET "clk2_pin_p" TNM_NET = clk2_pin_p;
TIMESPEC TS_clk2_pin = PERIOD "clk_pin_p" TS_clk_pin * 2 PHASE +1ns HIGH 50%;

 

This defines TS_clk2_pin as being related to TS_clk_pin with twice the PERIOD (so half the frequency) and a 1ns phase shift between the rising edge of clk_pin_p and clk2_pin_p

 

  2) You recommend to use FIFO to deal with mesochronous CDC. I agree with your recommend. But how to creat “two mesochronous clks” constraint in XDC and UCF to tell Xilinx tool their “not known phase” relation?

 

You can't. In both languages it is up to you to manage the relationships between clocks.

 

In Vivado, all clocks are assumed to be synchronous by default. If the two clocks are asynchronous or mesochronous, it is up to you to put in the appropriate CDC and constraints - in most cases a set_max_delay -datapath_only.

 

One tool available is the report_clock_interaction report (or the graphic version thereof) - you need to review every combination and determine if the tool's understanding of the clocks is correct. If the box is colored green (synchronous - no exceptions) but the clocks are actually mesochronous, it is your responsibility to put appropriate constraints on the paths.

 

In UCF the same is true, but starting from the clocks being unrelated. Again, you need a CDC and the appropriate constraints - a FROM TO DATAPATH_ONLY.

 

3) What’s Vivado different from ISE is that Vivado regards all clks as related clks and Vivado will analyse all clks’ paths. If Not using “asynchronous clock group” and there are two actual asynchronous clocks, what should I do to tell Vivado that these two clks are asynchronous?

 

There is no value in telling the tool they are asynchronous. You need to tell the tool the constraints on paths between them. This (rarely) is done by a set_false_path or set_clock_groups, but more often with a set_max_delay -datapath_only.

 

4) ...

 

I don't agree with calling them looser or tighter - they are different. The requirements on synchronous paths are governed by certain rules using information about the clocks. The requirements on mesochronous or asynchronous paths are governed by constraints, which are, in turn, governed by the requirements of the CDC between them. It is your responsibility to ensure that these are correct.

 

Your argument about using the MMCM vs. using different clock inputs is not true (particularly in Vivado). If the clocks are synchronous then make sure your constraints indicate that they are synchronous. This is the default in Vivado (always) and in ISE if the clocks come from the same MMCM/PLL. If they are not synchronous, then override the requirements with appropriate timing exceptions.

 

The same is true of different clocks coming in on different pins from an external PLL. Just because they come in on different pins doesn't mean they are mesochronous - if two clocks come in on different pins from a clock distribution chip, then the phase between them is known and may be tight enough for synchronous clock crossing. If they are, then define them as such, and if they are not then put in the appropriate exceptions.

 

Avrum

View solution in original post

Tags (3)
0 Kudos
3 Replies
Highlighted
Guide
Guide
4,421 Views
Registered: ‎01-23-2009

First, let me start by saying that I disagree with the whole concept of "Asynchronous clock groups" (i.e. the set_clock_groups command). I never use them - they are generally poorly understood and extremely dangerous.

 

When you have two clocks, they can have three different types of relationships:

  a) synchronous:

      - they trace back to the same clock source, so they have an exact frequency relationship

         - this may be 1:1, but it also may be 1:N, N:1, or even N:M where N and M are reasonable integers

      - they have a known maximum phase error between the clocks

         - i.e. for the rising edges that coincides the phase difference between the clock is x +/- y,

          - x may be anything from 0 to 360 degrees

          - y must be small - less significantly a full period (conservatively 45 degrees or less)

  b) asynchronous:

     - they do not trace back to a common clock source. Therefore, by definition there is no fixed phase relationship between them

  c) mesochronous:

     - this is a special case between the two. The two clocks trace back to the same clock source, therefore there is an exact frequency relationship between them

         - again 1:1 or 1:N or N:1 or N:M)

     - however, there is no known phase relationship between them (i.e. the phase error between them is large and/or unknown)

 

So your questions:

 

1) As long as they come from the same source (oscillator, PLL), and the frequency relationship between them is fixed and the phase between them is known they should be described as synchronous to each other (which is the default in Vivado). You can cross between these domains without a clock domain crossing circuit (CDC) as long as you completely describe the phase relationship between them, including any uncertainty in order

 

2) Again, stay away from the concept of clock groups - that is a separate question. However, these two clocks are mesochronous. You need a mesochronous CDC between them. A shallow clock crossing FIFO is usually sufficient - the depth of the FIFO only needs to be twice the maximum phase error divided by the period of the clock. Generally an 8 entry FIFO is sufficient; distributed RAMs can do 64 entry FIFOs cheaply, so they are the best choice.

 

3) These clocks are synchronous, you don't need a CDC between them as long as the phase error is something you can manage (for example a 10 degree phase difference on a fast clock may be difficult to meet timing with, but a 60 or 90 degree difference is probably fine)

 

4) What you say is true, but PVT variation on a board is usually pretty minimal (like around 5% to 10%) as opposed to PVT variation of silicon (which is generally around 300%).

 

5) I don't understand you question, but I should have already answered it. If you describe the clocks accurately, including the set_clock_uncertainty -from <clka> -to <clkb> (and vice versa), then you give STA the information it needs. If the tool says STA passes timing, then it is OK

 

But back to the set_clock_groups. All set_clock_groups does is declare all paths between the groups as false. This is almost never the correct thing to do. People often do this between asynchronous clocks, but it is usually an error. If there are paths between asynchronous clocks, then you need CDC circuits on any paths between them, and most of these CDC circuits require constraints to operate properly. By using the set_clock_groups command between them, you disable all timing, thus breaking the CDC. Do not use the set_clock_groups command (unless you really really really know what you are doing, and are 100% certain it is the correct thing to do - it almost never is).

 

Now for your next set of questions.

 

1) The tool automatically generates all relationships between clocks coming out of the same MMCM/PLL. They are all synchronous by default, even if they have different frequencies or phases. The tools will perform correct synchronous STA on any path between them. If they pass, then the design will work.

 

2) If there are no paths between a pair of clocks, there is nothing for STA to analyze, so there is nothing to even think about here.

 

From what I have said above you should have the answers to the rest of your questions...

 

Avrum

0 Kudos
Highlighted
Observer
Observer
4,404 Views
Registered: ‎02-26-2014

Hi, Avrum:

   After Reading your reply, Part of my puzzle is eliminated. But there are still questions are needed to be explained.

   1) As I know, the Xilinx tool ISE 14.7’s default set is to regard clks from different pins as asynchronous clock. So ISE will not analyze the path between them. However, if there are two clks coming from same PLL IC with determinacy phase relation. How to constraint them in UCF to tell ISE?

 

   2) You recommend to use FIFO to deal with mesochronous CDC. I agree with your recommend. But how to creat “two mesochronous clks” constraint in XDC and UCF to tell Xilinx tool their “not known phase” relation?

 

  3) What’s Vivado different from ISE is that Vivado regards all clks as related clks and Vivado will analyse all clks’ paths. If Not using “asynchronous clock group” and there are two actual asynchronous clocks, what should I do to tell Vivado that these two clks are asynchronous?

 

  4) Obviously, from the point of constraint, asynchronous is looser than mesochronous, mesochronous is looser than synchronous. So I think the complexity to place and route is asynchronous < mesochronous < synchronous. If two mesochronous clks are required, there are two methods to satisfy the need:

     a) Using the MMCM in FPGA to generate two synchronous clks means that: “synchronous” constraint take the place of “mesochronous”. The cost is more complex to place.

     b) Replace the MMCM and use two outputs coming from the same PLL IC’s output. This way means that Hardware architecture meets “mesochronous”.

  Which one is your recommend and give your expiation in detail about these two methods’ difference.

0 Kudos
Highlighted
Guide
Guide
7,175 Views
Registered: ‎01-23-2009

1) As I know, the Xilinx tool ISE 14.7’s default set is to regard clks from different pins as asynchronous clock. So ISE will not analyze the path between them. However, if there are two clks coming from same PLL IC with determinacy phase relation. How to constraint them in UCF to tell ISE?

 

There is a special format for creating related clocks in UCF - you use the TIMESPEC name of the first one in the creation of the second one

 

NET "clk_pin_p" TNM_NET = clk_pin_p;
TIMESPEC TS_clk_pin = PERIOD "clk_pin_p" 5 ns HIGH 50%;

NET "clk2_pin_p" TNM_NET = clk2_pin_p;
TIMESPEC TS_clk2_pin = PERIOD "clk_pin_p" TS_clk_pin * 2 PHASE +1ns HIGH 50%;

 

This defines TS_clk2_pin as being related to TS_clk_pin with twice the PERIOD (so half the frequency) and a 1ns phase shift between the rising edge of clk_pin_p and clk2_pin_p

 

  2) You recommend to use FIFO to deal with mesochronous CDC. I agree with your recommend. But how to creat “two mesochronous clks” constraint in XDC and UCF to tell Xilinx tool their “not known phase” relation?

 

You can't. In both languages it is up to you to manage the relationships between clocks.

 

In Vivado, all clocks are assumed to be synchronous by default. If the two clocks are asynchronous or mesochronous, it is up to you to put in the appropriate CDC and constraints - in most cases a set_max_delay -datapath_only.

 

One tool available is the report_clock_interaction report (or the graphic version thereof) - you need to review every combination and determine if the tool's understanding of the clocks is correct. If the box is colored green (synchronous - no exceptions) but the clocks are actually mesochronous, it is your responsibility to put appropriate constraints on the paths.

 

In UCF the same is true, but starting from the clocks being unrelated. Again, you need a CDC and the appropriate constraints - a FROM TO DATAPATH_ONLY.

 

3) What’s Vivado different from ISE is that Vivado regards all clks as related clks and Vivado will analyse all clks’ paths. If Not using “asynchronous clock group” and there are two actual asynchronous clocks, what should I do to tell Vivado that these two clks are asynchronous?

 

There is no value in telling the tool they are asynchronous. You need to tell the tool the constraints on paths between them. This (rarely) is done by a set_false_path or set_clock_groups, but more often with a set_max_delay -datapath_only.

 

4) ...

 

I don't agree with calling them looser or tighter - they are different. The requirements on synchronous paths are governed by certain rules using information about the clocks. The requirements on mesochronous or asynchronous paths are governed by constraints, which are, in turn, governed by the requirements of the CDC between them. It is your responsibility to ensure that these are correct.

 

Your argument about using the MMCM vs. using different clock inputs is not true (particularly in Vivado). If the clocks are synchronous then make sure your constraints indicate that they are synchronous. This is the default in Vivado (always) and in ISE if the clocks come from the same MMCM/PLL. If they are not synchronous, then override the requirements with appropriate timing exceptions.

 

The same is true of different clocks coming in on different pins from an external PLL. Just because they come in on different pins doesn't mean they are mesochronous - if two clocks come in on different pins from a clock distribution chip, then the phase between them is known and may be tight enough for synchronous clock crossing. If they are, then define them as such, and if they are not then put in the appropriate exceptions.

 

Avrum

View solution in original post

Tags (3)
0 Kudos