03-30-2021 08:14 AM
I keep having the same question and so I thought I'd put it out there and see if anyone else has had the same question, or better still an answer!
In our designs we usually have a main clock "clk" which clocks our main datapath. Often we also want a x2 version of this clock "clk_x2" which we can use for minimizing area of critical bits of the design for example.
Ideally you want a fixed phase relationship between the two clocks to avoid any metastability problems. If you do it right you don't need an async FIFO or anything! This is the case where both clocks come from the same MMCM and so have a fixed phase relationship. So normally I'd say just do that.
However, that's not always possible... One example is when your "clk" comes from a GT transmitting the output of your datapath. In that case your "clk" comes out of the GT, and not an MMCM you have access to. You must supply data to the GT on that clock. A clk_x2 generated from this clock will have an unpredictable skew with respect to clk. I guess it depends on the delay from the source of "clk" and the ref clock input of the MMCM, which changes from build to build. An equivalent example is when you've got a MIG and you're sending your data to a DRAM. The MIG outputs your "clk". In both these examples, both "clk" and "clk_x2" can't come from the same MMCM, and so don.t have deterministic phase, as far as I can tell.
So my questions are:
- Is there a way to guarantee the phase relationship between the two clocks in this setup - with one as the input to an MMCM and the other an output? Is there some constraint magic I'm missing?
- If not, what have others done in this situation? One idea I had was to use an MMCM to generate both clocks clk_x1 and clk_x2 based on the clk given to us by the GT or the MIG. In this case I'd then need some mechanism to get data from the "clk_x1" out of the MMCM back to the "clk"..
- Am I over worrying? do the tools understand all this and fix the problems in place and route?
03-30-2021 10:16 AM
So, first, the output of the MMCM is "somewhat aligned" to the input of the MMCM - in fact the MMCM is actively working to keep the CLKIN and CLKFBIN in phase (with some fixed phase difference depending on what is feeding the CLKIN). So you need to question "which version" of the clock do you want to keep in phase...
In a "normal" MMCM setup, there is a BUFG in the CLKFBOUT->CLKFBIN path of the MMCM. This therefore aligns the input clock (at the CLKIN of the MMCM or at the input port feeding the CLKIN of the MMCM) to the leaves of the clock distribution network. If you have a BUFG on your input clock (for your "non MMCM" path) a BUFG on your CLKFBOUT -> CLKFBIN path and a BUFG on your CLKOUT0 path, then you end up with the equivalent of one clock insertion difference between your two clocks.
In theory, if you don't put a BUFG on the CLKFBOUT -> CLKFBIN path then your two clocks will be "more" in phase. Doing this (not having a buffer on the CLKFBOUT -> CLKFBIN path) is legal, but:
Regardless of how you implement the clock feedback, the tools fully understand the timing of these clocks. If (with no exceptions) the tools say that it can pass timing with these cross clock paths, then the skew between the clocks is low enough for the tools to fix timing (which may involve lots of routing to fix hold times). If they can't then you will get failing paths... So the tools will let you know.
The better solution is to have both clocks come as outputs of the same MMCM. I haven't investigated the restrictions for the GTx CLKOUT -> USRCLK paths lately, but it certainly was legal in some configurations in the past to use an MMCM on this path (in fact, there was an errata in an early GTx that required the MMCM in the path). Someone more up to date with the GT clocking requirements would have to tell you if this is legal ( maybe @roym ? )
03-30-2021 12:06 PM
I'm afraid I can't shed much light here. For the GT, the outclk is sometimes 2X the frequency needed for the 'USRCLK2. The MMCM is no longer used for this as the BUFG_GT has the ability 2 do the divide by 2 and keep the skew relationship where it needs to be. This is the only way of doing this in device families later than the 7-series.
04-04-2021 08:58 AM
One other thing to look at is to use the BUFR dividers in the 7 series chips as a divide by two,