08-19-2020 02:04 PM
This question is about HOW to force a PLL to align oddly related clocks. It's complicated, so I must provide some detail first...
I have a PLL producing three different clocks. See the bottom three graphs in the image below.
txclk(CLK) runs with 3.36ns period. Call this the 3.5x clock because it's 3.5 times faster than pixel_clk
txclk_div(CLKDIV) runs with 23.53ns period. Call this the 0.5x clock because it's half as fast as the pixel_clk.
pixel_clk runs with 11.76ns period.
Notice in my graph above that all three of the bottom three trace rise at the same time, time 0. This is PROPER phase alignment.
It turns out, that pixel_clk starts up in one of 7 different alignment positions, as seen by versions (a) through (g) in the graph. All of these versions are in sync with txclk(CLK). But only one of the seven is in sync with txclk_div(CLKDIV). Version (f) happens to be in inverse sync; that is, pixel_clk(f) falls when txclk_div(CLKDIV) rises. For larger purposes, this one's acceptable as well as version (a). So I find myself in a position where only 2 of 7 possible startup conditions works.
Here's more detail. I have an old version of code that starts up correctly every time. This version has a source coming INTO the PLL with the same frequency as pixel_clk. Therefore, while the PLL has 3 outputs (CLKOUT0, CLKOUT1, CLKOUT2) configured, this code is only using the first 2 of the 3 outputs. Instead of using CLKOUT2, it's using the CLKFBOUT. This works because the incoming source is the same frequency as pixel_clk, that would have been on CLKOUT2. This code seems to synchronize CLKOUT1 [aka txclk(CLKDIV)] and CLKOUT2 [aka txclk_div(CLKDIV)] to CLKFBOUT [aka pixel_clk]. Therefore, spoken in reverse, pixel_clk is therefore sync'd with both txclk(CLKDIV) and txclk_div(CLKDIV).
My newer code must have a yet different source clock. So it can't drive pixel_clk from CLKFBOUT. Instead it's actually using that CLKOUT2. Now, however, it seems that pixel_clk is sync'd with txclk(CLKDIV), and txclk_div(DIVCLK) is also sync'd with txclk(CLKDIV), ***however*** pixel_clk is ***not*** sync'd with txclk_div(DIVCLK). Expressed another way, CLKOUT2 and CLKOUT1 are sync'd with CLKOUT0, but CLKOUT2 is not sync'd with CLKOUT1.
Is there a way to get CLKOUT2 and CLKOUT1 sync'd?
Alternatively, is it in fact the case that CLKOUT2 and CLKOUT1 are definitely sync'd with CLKOUT0, or was that just a coincidence? If sync'd for sure, then I could swap the roles of the clock outputs. That is, I could configure and connect CLKOUT0 to pixel_clk, CLKOUT1 remains txclk_div(CLKDIV), and configure and connect CLKOUT2 to txclk(CLKDIV). Thus, if CLKOUT2 and CLKOUT1 are indeed always sync'd with CLKOUT0, then I will end up with pixel_clk sync'd to both txclk_div(CLKDIV) and txclk(CLK). Meanwhile in this case, txclk_div(CLKDIV) and txclk(CLK) will also be sync'd to one another because they the period of txclk_div(CLK) is an even multiple of txclk(CLK).
Will the above swapping of CLKOUT0 and CLKOUT2 work? Or is it ***not*** necessarily the case that CLKOUT2 and CLKOUT1 are always sync'd with CLKOUT0?
08-20-2020 05:05 AM - edited 08-20-2020 05:06 AM
First, for this to work, the periods for your three clocks must be exactly related in the ratio 0.5:1.0:3.5 (or 1:2:7).
Next, the following setup for an MMCM should give you the alignment you want (ie. pixel_clk(a), txclk_div, txclk in your waveform diagram):
Note: only on every other cycle of pixel_clk will the rising-edge of pixel_clk align with the rising-edge of txclk – because the period for pixel_clk is not an integer multiple of the period for txclk.
08-20-2020 07:03 AM
Thanks, firstname.lastname@example.org , but this won't solve my problem... Maybe...
Indeed, my OLD code does exactly this with CMT#1 (Clock Management Tile #1). The old code was for a fixed pixel_clk and therefore received the desired pixel_clk from a separate main CMT#2 used for the whole design.
However, the NEW code must have an adjustable pixel_clk. I'm using DRP to adjust the CMT#1. Since in this case CLKIN is fixed, it can't serve also as pixel_clk which must be adjustable via DRP. I need a separate pixel_clk output that's different from CLKIN1. That's what I'm trying to figure out.
If In order to implement the same as above I would have to use up either a third CMT, or complicate system integration flexibility by forcing the DRP adjustment onto CMT#2, which otherwise doesn't know about the complexity of the subsystem using CMT#1.
ON THE OTHER HAND... My OLD code was configured to generate a clone of CLKIN1 on CLKOUT2, but that output was *not* wired up to the pixel_clk output of the module. Instead, CLKFBOUT was used. I don't know the phase relationship of CLKFBOUT to CLKOUT2, but you imply it should be 0 with rising edges aligned.
ON THE THIRD HAND... My NEW code had to change the above and actually use CLKOUT2, with now CLKIN1 being different from all three outputs. For division capability to hit the desired pixel_clk values (20MHz, 45MHz, 85MHz), CLKIN1 is 70MHz. Actually, 70MHz CLKIN1 makes the math work for setting pixel_clk this year to any of those three, but next year to any multiple of 5MHz in that range. Well, anyway, now that CLKOUT2 no longer equals CLKIN1 in period, I find my current situation. CLKOUT1 and CLKOUT2 are both sync'd to CLKOUT0 I *believe* (tough to tell for absolute certain), but CLKOUT1 and CLKOUT2 are *not* sync'd.
ON THE FOURTH HAND (I'm running out of hands...)... You ordered your text in increasing order when you wrote 1:2:7. Note that the current new code has the outputs in order 7:1:2. Might that make a difference? I was thinking about swapping CLKOUT0 and CLKOUT2 so that my outputs became in the order 2:1:7. I *wondered* if this would force 2:1 to be sync'd and 2:7 to be sync'd, and since they are an even multiple of one another, so would be 1:7 also sync'd, thus all three.
ON THE FIFTH HAND (ok, I'm out of feet too now...)... I could in fact re-order to 1:2:7. It just takes a little more care in modifying all the references in the low level code module. If I did that, but had a DIFFERENT CLKIN1, would they all sync up.
ON THE SIXTH HAND... let's consider that 70MHz input. I don't remember the math detail, but I chose it because it made it possible to mult/divide and get all values of pixel_clk from 20..85 in multiples of 5. I could reconsider that math. And since only implementing 20,45,85 right now, I could perhaps forgo that restriction. HERE IS WHY I CONSIDER THIS. We've written about 1:2:7. Putting 70MHz into that context I get some number between 3.5 (whenever pixel_clk equals 20MHz) and 0.8235... (whenever pixel_clk equals 85MHz). Those aren't nice integers. The only common divisor of 20,45,85 is 5. I could chose CLKIN1 to be 5MHz instead, but I think that's too slow, isn't it? If not, then my ratios for CLKIN1:CLKOUT0:CLKOUT1:CLKOUT2 would be 1:2:4:14@20MHz, 1:4.5:9:31.5@45MHz (realized problem already, not all integers), and 1:8.5:17:59.5@85MHz. Will what you say, email@example.com , still work with those non-integer ratios? Will it work with non-integer ration from CLKIN1? If so, then my 70MHz should have been fine from the beginning... This sends me back to my fifth hand. What if I tried 3060MHz, the common multiple? Too fast. Coming back to this hand, is that 0.8235 ratio a problem with I try to configure for 85MHz? (The problem did persist at 20MHz.) If 0.8235 were a problem, then 5MHz input fixed that. At worst there's a .5 in a couple ratios. But I don't like the slowness of 5MHz for the accuracy of the higher frequencies.
ON THE SEVENTH HAND... Can CLKFBOUT be an even multiple of CLKIN1 rather than exactly equal to it? Or perhaps a N.5 multiple? The parameters seem to make that possible. Might this lead me to a solution? I keep CLKFBOUT as my pixel_clk, but it's *not* equal to CLKIN1, but is some nice integer or fractional multiple that has sync edges frequently enough (like the 5MHz CLKIN1 example I don't like).
Now what, LOL?
08-20-2020 02:21 PM
My associate wanted diagrams. So here they are for you, too:
FIXED CLOCK CODE: (all three clocks properly sync'd, because one of the three is actually equal to the input and the feedback)
* Fixed freq into CLKIN1 matches desired pixel_clk
* CLKFBOUT ties to CLKFBIN and is used as pixel_clk,
VARIABLE CODE: (all three clocks NOT aligned, as described elsewhere in post)
* 70MHz into CLKIN1. Source not seen in schematic below.
* CLKFBOUT ties to CLKFBIN through a BUFG.
* txclk, txclk_div, and pixel_clk come from CLKOUT0, CLKOUT1, CLKOUT2 respectively
All the state machine to control the DRP stuff complicates this module, so this is a crop of the whole module.
08-20-2020 05:37 PM
Gosh, Helmut ! I’m not sure I’m young enough to think that hard anymore. However, here’s a few more thoughts before I go ice my head.
After seeing your plan to create output clocks that do not have frequencies with nice integer ratios but still need to be phase aligned, I had to go get the ice.
Please tell us why you need the phase alignment between the output clocks. Are you attempting direct crossing of data between the clock domains? Maybe it is easier to give-up on this phase-alignment idea and instead use asynchronous data crossing techniques (eg. a FIFO or handshake synchronizer)?
08-20-2020 10:11 PM
Thanks for the humor, firstname.lastname@example.org . A life without humor isn't a life worth living. Yes, my brain hurts, too.
Corresponding number responses...
1. OK, I see output (3) phase aligned with output (5). But I see those NOT phase aligned with (1), (4), (6). Presumably this is by example and the specs on (3), (5) were to be offset from (1), (4), (6). NOTE that that timing diagram only shows one edge, however. I think when multiple edges are shown, more nuance can be seen. Specifically, if there's a fractional relationship between clocks, which fraction is aligned?
2. OK. Assumed...
3. Your first sentence says the rising edges of all clocks should align when the CMT starts outputting clocks. This should be good, and my fractional relationship mention above is hopefully not problematic. Then your next sentence mentions "next CMT startup". Are you specifically saying "next CMT startup" because you're talking about after my DRP has adjusted clock rates? Or are you saying that for some other reason?
4. Here you mention nice integer ratios. Here you imply everything should already be coming out aligned. The only problem is that it's not. At least I'm pretty sure it's not; measuring skew between these internal clocks is tough.
5. LOL, it's not me that wants these clocks aligned. It's legacy Xilinx code for 7:1 OSERDES that I'm using to support Camera Link video output. Specifically, XAPP585 v1.1.2 July 2018 OrgVerilogVersion serdes_7_to_1_diff_ddr.v . Yes indeed it has some possibly sloppy clock domain crossing (CDC) in it, between a txclk_div always block and a pixel_clk always block and then back into the OSERDESE2's clocked by txclk and txclk_div. I was also thinking about focusing on cleaning those up. That was when I thought the clock misalignment may have been just a few degrees. But then a couple days ago I got to strongly believing that pixel_clk is one whole txclk half-cycle misaligned from txclk_div. That pixel_clk vs txclk_div misalignment strongly feeds the poor CDC. So I changed tactics to trying to realign the clocks. Yes, I might have to go back to rewriting the CDC.
Note in all of this, it's very tough to be sure. txclk is running at 297.5MHz, and my fastest other internal clock is 200MHz. I tried an ILA clocked by txclk and capturing txclk_div and pixel_clk, but I have yet to get it to meet timing. Instead, I'm looking at "aliased" captures of the clocks and deciphering what the actual clock timing might be. I'm simultaneously trying to get a 70MHz txclk version running, with all other clocks slowed appropriately, then captured with 200MHz system clock.
Note, in going around the block, I might in fact now be in a better place to try to rewrite the CDC. I have a scale drawing now that originated from the "aliased" captures. On separate paper, I drew the known clock periods. Then I held that second sheet on top of the aliased captures sheet, to determine quite closely where the actual edges must be relative to the aliased capture clock. I think my drawing is now "true", and that's where I discovered the gross misalignment. Given that diagram now, I may be able to fathom the exact problem with the CDC. LOL, of course part of this is the timing going into the SERDES. Ah, but those two clocks DO seem to be aligned. Again, the drawing is giving me insight I didn't have before. Meanwhile, I'm strongly considering building a specific local testbench, reduced in complexity from the remote (LOL) target exhibiting the problem.
08-21-2020 03:57 PM
Specifically, if there's a fractional relationship between clocks, which fraction is aligned?
For example, if frequency of CLK1 and CLK2 are related by ratio of 2/3:1 then you can multiply both sides of the ratio by 3 to get the nice integer ratio of 2:3. So, every 2 cycles of CLK1 (which is equivalent to 3 cycles of CLK2), rising-edges will align.
Are you specifically saying "next CMT startup" because you're talking about after my DRP has adjusted clock rates? Or are you saying that for some other reason?
Without the DRP, rising-edge alignment might not occur for many clock cycles - or until "next CMT startup". With the DRP, rising-edge alignment should occur when you bring the CMT out of reset (ref document XAPP888).
...you imply everything should already be coming out aligned. The only problem is that it's not. At least I'm pretty sure it's not; measuring skew between these internal clocks is tough.
If you use the same type clock buffer (BUFG in my example) on all the clock outputs of the CMT and the clocks are integer-ratio-related (ie. they theoretically should have some aligned edges) then you have done the best you can do. Clock skew is really a different animal. However, timing analysis includes clock skew and can automatically direct implementation to help reduce clock skew. Sometimes however (eg. the FPGA external interface to an ADC) we must manually add delay (eg. IDELAY, ODELAY) to de-skew clock and data.
08-22-2020 05:33 AM
email@example.com thanks yet again for sticking with me on this one. I do sincerely appreciate it.
Let's get down to very, very simple...
Consider CLKOUT0, CLKOUT1, and CLKOUT2. You imply that if CLKOUT0 and CLKOUT1 have a 3:2 ratio, then every 3 cycles of CLKOUT0 (equivalent to 2 cycles of CLKOUT1), will have rising edges aligned. Great.
This further implies that if CLKOUT0 and CLKOUT2 have a 3:1 ratio, then every 3 cycles of CLKOUT0 (equivalent to 1 cycle of CLKOUT2), will have rising edges aligned. Great.
PROBLEM: What about the relationship between CLKOUT1 and CLKOUT2? Their ratio should be 2:1, but an ambiguity arises about the rising edge alignment. Look at my drawing below and you'll see that one of two scenarios might result for the rising edge of CLKOUT2, shown as CLKOUT2(a) and CLKOUT2(b). See that CLKOUT0 and CLKOUT1 have a 3:2 ratio of period, and they have aligned rising edges periodically, including in my drawing at time 0. See also that CLKOUT0 and CLKOUT2(a) have a ratio of 3:1 and they also have aligned rising edges periodically, including in my drawing at time 0. Furthermore, CLKOUT1 and CLKOUT2(a) have a ratio of 2:1 and they furthermore have aligned rising edges periodically, including in my drawing at time 0.
HOWEVER, consider CLKOUT2(b). Indeed, CLKOUT0 and CLKOUT2(b) have a ratio of 3:1. Furthermore they do indeed have aligned rising edges periodically. They don't include time 0 in my drawing, but time 0 could be called relative anyway. The problem here is we see that CLKOUT1 and CLKOUT2(b) might be in a 2:1 ratio, but their rising edges are NEVER aligned. Nor are their falling edges.
Well, I could phrase this exact same problem differently and the problem would SEEM to go away. That is, if I swapped the rolls of CLKOUT0 and CLKOUT1, I would end up describing ratios of 2:3 and 2:1. The ambiguity doesn't arise.
THE SECRET HERE is that in writing the description and making our assertion, we were treating the first mentioned clock, CLKOUT0, as special. We made the assumption that all other clocks WILL have a sync rising edge at some point with CLKOUT0, the special reference. Depending on which of the three clock rates is put on CLKOUT0, we do or don't find a potential problem between CLKOUT1 and CLKOUT2. But if the hardware is truly agnostic as to which clock is where on the outputs, then our original statement can NOT be relied upon. That assumption is sometimes FALSE. This is the crux of the problem. This is why I asked if CLKOUT0 was in fact special.
To prove what I'm saying, look at the drawing below. I have simply swapped the rates for CLKOUT0 and CLKOUT1. Indeed it remains true that CLKOUT1 sometimes has rising edges aligned with CLKOUT0, including at time 0 in my drawing. Furthermore, it remains true that CLKOUT2(a) sometimes has rising edges aligned with CLKOUT0, including at time 0 in my drawing. But look at CLKOUT2(b). We would say that could never happen because, by our own presumptive assertion, CLKOUT2(b) never has a rising edge aligned with CLKOUT0, while that's what we have said must happen.
The difference in the drawing is nothing more than the labels. It is out assertion that is based on CLKOUT0, such that when we change CLKOUT0 we change our assertion. Our assertion ASSUMES that CLKOUT0 is special. But if the hardware is agnostic, then our assertion MUST BE WRONG. Which is it?
Well, let's more forward... Perhaps there IS a special clock, and perhaps it's CLKFBOUT. Does anybody know this for sure? If the alignment assertion can be made about all output clocks relative to CLKFBOUT, and simultaneously one can NOT assume any alignment between any other output clocks, then consistency arises. In this case, it doesn't matter which output clock is which. It only matters that CLKFBOUT is special.
IFF (IF and ONLY IF) CLKFBOUT is in fact and indeed the "special one", then what does this mean to me? I'll jump straight to the question. Does CLKFBOUT have to be the same frequency as CLKIN1, or can they be different by some integer ratio?
I would greatly prefer CLKIN1 to be fixed. But I need CLKOUT0, CLKOUT1, and CLKOUT2 to be reconfigurable through DRP. In terms of this example, the middle-rate clock needs to be the "special one". That will help it align with both the slower clock and the faster clock. Then the slower clock and the faster clock themselves will automatically be aligned as well because they have a 1:N ratio; that is, if the slower clock ever aligns with the "special one", which it does, then the faster clock will also align at the same time because the faster clock has a rising edge for *every* rising edge of the slower clock. Well, in order for the middle-rate clock to be the "special one", it must also equal CLKFBOUT. But I want CLKIN1 to be fixed and the middle-rate clock adjustable. The only way to make this happen is for CLKFBOUT to be adjustable while CLKIN1 is fixed; therefore CLKFBOUT is ***not*** always equal to CLKIN1. Back to my question above in red...
08-22-2020 05:48 AM - edited 08-22-2020 06:40 AM
Note: UG472 v1.14 page 74 right under Equation 3-4 reads "It is possible to phase shift the CLKFBOUT feedback clock. In that case all CLKOUT output clocks are negatively phase shifted with respect to CLKIN." This refines prior implications in the document and strengthens the implication that phase alignment is in fact relative to CLKFBOUT. (Earlier, page 72 read "In this case, all output clocks have a defined phase relationship to the input reference clock." Well, that was "in this case". My page 74 quote seems to clarify that the page 72 quote was only "the case" because CLKFBOUT had no phase shift in it relative to CLKIN. Note that I do feel a bit of logical recursion creeping in here. That is, how can CLKFBOUT have a phase shift relative to the "special one" if it is itself the "special one". So CLKFBOUT's phase relationship is to CLKIN. And if that's the case, why aren't the all! ARGH!!!)
Note: UG472 v1.14 where on earth did "REFCLK" come from in Figure 3-20 on page 101? I'd really like to know!
Note: UG472 v1.14 defines CLKOUT[0:6]_PHASE as a phase relationship. Well, folks, a phase relationship requires a point of reference, and the point of reference is NOT provided in the doc. Is the point of reference [CLKFBOUT or CLKFB] of Figures 3-2 and 3-3? That is, see the selector with CLKFBOUT and CLKFB as inputs, which then feeds into the PFD (phase-frequency detector). That is, is this [CLKFBOUT or CLKFB] output the "special one"?
I seem to be coming to the point that, even if I'm right about CLKFBOUT being the "special one" when appropriately configured, and different from CLKIN1 (which maybe it always has been), it's going to be impossible to set it to a magic value to make things work. I consider my DRP parameters below. There's one set for each desired pixel_clk freq of 20MHz, 45MHz, or 85MHz. It seems that CLKFBOUT must always be the fastest of all the clocks, and so can't be the "middle one" to get what I'm seeking. I may have no choice but to fix the XAPP??? poor CDC. Note that these values are based on a 70MHz incoming clock. I don't think changing that clock is going to help things.
// DRP DEFINES ULTRASCALE SERIES 7 localparam CLKFBOUT_MULT_20MHZ = (ULTRASCALE == "TRUE") ? 14 : 14 ; localparam CLKOUT0_DIVIDE_20MHZ = (ULTRASCALE == "TRUE") ? 14 : 14 ; localparam CLKOUT1_DIVIDE_20MHZ = (ULTRASCALE == "TRUE") ? 28 : 98 ; localparam CLKOUT2_DIVIDE_20MHZ = (ULTRASCALE == "TRUE") ? 49 : 49 ; // localparam CLKFBOUT_MULT_45MHZ = (ULTRASCALE == "TRUE") ? 18 : 18 ; localparam CLKOUT0_DIVIDE_45MHZ = (ULTRASCALE == "TRUE") ? 8 : 8 ; localparam CLKOUT1_DIVIDE_45MHZ = (ULTRASCALE == "TRUE") ? 16 : 56 ; localparam CLKOUT2_DIVIDE_45MHZ = (ULTRASCALE == "TRUE") ? 28 : 28 ; // localparam CLKFBOUT_MULT_85MHZ = (ULTRASCALE == "TRUE") ? 17 : 17 ; localparam CLKOUT0_DIVIDE_85MHZ = (ULTRASCALE == "TRUE") ? 4 : 4 ; localparam CLKOUT1_DIVIDE_85MHZ = (ULTRASCALE == "TRUE") ? 8 : 28 ; localparam CLKOUT2_DIVIDE_85MHZ = (ULTRASCALE == "TRUE") ? 14 : 14 ;
08-22-2020 10:28 AM
There is no "special clock"...
The way the MMCM and PLL work is that they generate an internal VCO frequency (fVCO), which is fVCO=fIN*M/D (where M is CLKFBOUT_MULT_F and D is CLKIN_DIVIDE). The tool chooses the M and D to find an fVCO that meets the internal needs (limits on the VCO frequency and on the PFD ), is the highest it can be (for performance purposes) and can be divided (either by integer or fractional divide) to generate the output clocks. This VCO clock is the special clock.
All the outputs are merely dividers based on this fVCO. In the case of CLKOUT0, this can be a divider that is a multiple of 1/8, for the others, it is an integer.
All these dividers are running on the VCO clock - they are synchronous to each other internally in the MMCM/PLL. When the MMCM/PLL is in reset, all these dividers are reset. On the deassertion of the reset, they come out of reset "together". In other words, on the deassertion of reset, they all start their counters at 0 together. This fundamentally ensures that any periodicity that exists between the outputs lines up - they all started with their "first" rising edge together. We know this to be true, and I haven't seen anyone complain about a problem with this.
But I don't know about the DRP. My understanding is that after reprogramming via the DRP, the reset is supposed to be reasserted, and the same reset sequence should happen again, which should result in the output clocks aligning. However, if you are not asserting this reset properly, then all bets are off. If you are asserting the reset properly, and this is really happening (the clocks are not aligned), then there is a problem - we would need to get Xilinx to look at this... My understanding is that its not supposed to be possible...
08-22-2020 04:02 PM - edited 08-22-2020 04:06 PM
The problem here is we see that CLKOUT1 and CLKOUT2(b) might be in a 2:1 ratio, but their rising edges are NEVER aligned. Nor are their falling edges.
If you have nice integer ratios between all the output clocks of the CMT and you do a proper reset (which automatically happens at CMT power-up) then all the output clocks of the CMT will startup with rising-edges aligned – as Avrum says. The only time I have seen this not happen is when I command the CMT to phase shift one of the output clocks.
THE SECRET HERE is that in writing the description and making our assertion, we were treating the first mentioned clock, CLKOUT0, as special. We made the assumption that all other clocks WILL have a sync rising edge at some point with CLKOUT0, the special reference.
As Avrum says, none of the clock outputs are SPECIAL. Well, maybe CLKFBOUT is special - but not in the way you say (please see my answer to your next question below). Again, If you have nice integer ratios between all the clock output of the CMT and you do a proper reset then all the output clocks of the CMT will startup with rising-edges aligned.
Does CLKFBOUT have to be the same frequency as CLKIN1, or can they be different by some integer ratio?
I don’t know. When you use CLKFBOUT as shown in Fig 3-11 of UG472 (ie. only to feedback a clock to CLKFBIN) then you don’t need to ask this question. I recommend that you use CLKOUT0, CLKOUT1, CLKOUT2, etc (and not CLKFBOUT) for the CMT clock outputs.
Note: UG472 v1.14 defines CLKOUT[0:6]_PHASE as a phase relationship. Well, folks, a phase relationship requires a point of reference, and the point of reference is NOT provided in the doc.
The point of reference is the CMT startup point where all the output clocks have rising-edges aligned. If you specify CLKOUT0 to have a phase shift of 180degs then the first rising-edge of CLKOUT0 will occur 1/2-clock-cycle of CLKOUT0 after this point of reference. -and, the rising-edge of CLKOUT0 will not align with the rising-edge of the other output clocks of the CMT.
Maybe that's the point of confusion. Have the gremlins secretly commanded your CMT to phase shift one of the output clocks? Is this why you are not seeing alignment of the rising-edges - as you expect?
Finally, there is a random phase offset on clock outputs of the CMT called TSTATPHAOFFSET (see the MMCM and PLL tables in the datasheet for your device). However, this random phase offset is typically small ( ~ 0.12ns * 360deg/(clock period in ns) ).
08-29-2020 11:34 PM
The answers here keep saying "when properly reset". What's "properly reset" what clock edge does the reset align to? Could the problem be that a reset async to the "proper" clock means the output clock dividers are metastable at reset so don't effectively all start on the same "cycle 0" of the internal VCO clock being divided down? Or does it internally synchronize reset to avoid this?