We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎09-18-2007

Phase Matched Clocks in UltraScale

I need to create 2 programable rate clocks that always have a fixed ratio of 2:1 and are phase matched. Ie suppose I have a 100 MHz master clock, I need to create a pair of phase matched clocks at either: (100,50), (50,25), (25,12.5) MHz.

In Virtex-4 I did this with a Phase Matched Clock Divider (PMCD) primitive but there is no equivilent in UltraScale. I could use a DCM/MCMM and use the DRP port, but that seems a bit overkill.

Is there an alternative method?


BTW, I cannot run the half rate clock at full rate and use a synchronous div2 enable because I'm interfacing to a "black box" core.

0 Kudos
3 Replies
Registered: ‎08-08-2017

Re: Phase Matched Clocks in UltraScale

Hi @cbemlahe 

BTW, I cannot run the half rate clock at full rate and use a synchronous div2 enable because I'm interfacing to a "black box" core

-> Does it mean that you dont want to use the BUGGCE_DIV (General Clock Buffer with Divide Function).

BUFGCE_DIV is a general clock buffer with an enable and divide function and can be use to divide the clock by  1 (Bypass) , 2, 3, 4, 5, 6, 7, 8 .

Consider you want a pair of (100,50)  then clocking connection should be

100 MHZ (master clock)  ->  BUFGCE_DIV  (BUFGCE_DIVIDE = 1)   -> 100 Mhz clock output

                                        ->  BUFGCE_DIV  (BUFGCE_DIVIDE = 2)   ->  50 Mhz clock output.


Primitive instatiation is in UG974 page 220


Reply if you have any queries, give kudos and accept as solution
Registered: ‎09-18-2007

Re: Phase Matched Clocks in UltraScale

I could do that, but the clock division in the BUFG is set by generic is not configurable on-the-fly. What I could do is set them to divide by one and two and tie the inputs to the same user logic clock divider.

What I'm not sure about is if the timing/PAR tools automatically know that any logic crossing these two BUFG clocks are sourced from the same point.

If not I guess I'll need some sort of timing constraint.

0 Kudos
Registered: ‎01-23-2009

Re: Phase Matched Clocks in UltraScale

Do you care about the duty cycle of these clocks?

If not, then you can use the BUFGCE. From your 100MHz clock source you will need three BUFGCEs, all with their .I connected to the clock source.

One is a regular 100Mhz clock buffer - the CE is always 1'b1 (you can use a BUFG, which will actually infer this). This will be the clock that controls the other two.

The other two have their CE inputs driven from the control block:

  • For 100/50, the first one has the CE driven high for all clock cycles, the second has it driven high one out of every two
  • For 50/25 the first one will be driven high one out of every 2 and the other one out of every 4
  • etc...

Take a look at this post on using the BUFGCE (it's for older technologies, but the concept is the same).

Since the two programmable clocks are (presumably) expected to be synchronous to eachother you need to ensure that the enables are generated for the same clock period (i.e. the clock where the 25MHz one is enabled is the same as one of the two clocks where the 50MHz is enabled), but you also have to make sure that the two clocks are in the same CLOCK_DELAY_GROUP.

For constraints, you should constrain for the maximum frequency, which is 100MHz/50MHz. This means that you need no additional constraint for the 100MHz clock - it inherits from the input clock. For the one that is no more than 50MHz, you need to create a generated clock on the output of the BUFGCE - take a look at this post on constraining a divided clock on the BUFGCE.

With this mechanism, switching frequencies is really easy - your RTL that generates the CE's simply changes which clocks the CE is asserted on - no device reprogramming or control of Xilinx primitives is required.