cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
296 Views
Registered: ‎02-14-2020

How to constrain clock skew between the input and output of an MMCM

Hi!

   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?

Thanks!

Alex.

0 Kudos
4 Replies
avrumw
Guide
Guide
266 Views
Registered: ‎01-23-2009

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:

  • The two clocks still won't be perfectly in phase (as they would be if you used two outputs of the same MMCM)
  • This configuration has an uncompensated delay between the input clock and the clock at the leaves of the clock tree (either clock tree) - the clocks are somewhat phase matched at their roots (which is what you wanted)
    • This makes it "unacceptable" for clocking
      • an input interface
      • an output interface with system synchronous timing

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 ? )

Avrum

roym
Moderator
Moderator
250 Views
Registered: ‎07-30-2007

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.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


0 Kudos
136 Views
Registered: ‎02-14-2020

Thanks for your replies.

I think we'll try a few experiments based on what you've suggested

Alex

0 Kudos
drjohnsmith
Teacher
Teacher
73 Views
Registered: ‎07-09-2009

One other thing to look at is to use the BUFR dividers in the 7 series chips as a divide by two,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos