UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor cecillove
Visitor
4,664 Views
Registered: ‎09-27-2012

Decimated Clocks via BUFHCE

I am trying to two decimated clocks out of one clock coming from the mmcm so that I totally have 3 clocks in the system.

My application needs this.

First I tried to put a BUFGCE on the BUFG on the clock and the vivado drc check didn't allow it. This is series 7 part.

I understand that one possible way to do this is use BUFHCE on the BUFG and use  the clock enable on the BUFHCE to control the clock.

But I now have a problem. From the documentation BUFHCE is limited to only one clock region?

My consuming IPs for the two clocks can be spread across multiple regions.

 

My options are:

1. Can I create just two of the clocks using 2 BUFHCEs from the main clock and assume vivado will replicate the BUFHCE  as needed

2. Should I instead insert enough BUFHCEs and make sure that the loads on each will be well within a clock region capacity.

3. Is there any attribute like max fanout on BUFHCE which will make the tool do this for me?

 

thank you

 

 

 

 

 

0 Kudos
4 Replies
Historian
Historian
4,649 Views
Registered: ‎01-23-2009

Re: Decimated Clocks via BUFHCE

I presume you want these three clocks to be phase aligned so that you can cross synchronously between the 3 domains? To do this, all three clocks have the same types of clocking resources on all paths.

 

There are two ways to do this.

 

The reality is that every global domain (generated by a BUFG) goes through exactly one BUFH on its way to fabric logic. If you use the BUFG "directly" the tool infers the proper BUFHs at the time that it maps the logic resources to clock regions. Because of this, if you use a BUFHCE after a BUFG, then the manually instantiated BUFHCE is used instead of the automatically inserted BUFH, and hence the outputs of the clocks are balanced. But, as you mentioned, this restricts logic on the BUFHCE domain to one clock region (each). You can always manually partition the design and use multiple BUFHCEs with the same CE, but that is very cumbersome...

 

The other choice is to use BUFGCEs. But, you cannot (or should not) cascade BUFGs with BUFGCEs - these are the same resources.

 

So, what you should do is take the clock out of your MMCM output (say the CLKOUT0 output) and feed it directly to the .I input of three clock buffers; one BUFG, and two BUFGCEs (and drive the CE of the BUFGCEs as you need). Since each of the clocks goes through exactly one BUFGCTRL (which is the cell that is actually used to implement both a BUFG and a BUFGCE, as well as the BUFGMUX), the three clocks will be in phase.

 

Avrum

0 Kudos
Historian
Historian
4,646 Views
Registered: ‎01-23-2009

Re: Decimated Clocks via BUFHCE

If course, there is always the other solution - clock them all on the BUFG. For the FFs on the two decimated "domains" simply use the CE of the flip-flops...

 

Avrum

0 Kudos
Visitor cecillove
Visitor
4,626 Views
Registered: ‎09-27-2012

Re: Decimated Clocks via BUFHCE

Hi Avrum, This is perfect! One question is whether the mmcm compensation will still be effectively like it is for one clock? Or will it get confused seeing 3 buf* elements.

0 Kudos
Historian
Historian
4,597 Views
Registered: ‎01-23-2009

Re: Decimated Clocks via BUFHCE

There should be a fourth BUFG, which is connected between the CLKFBOUT and CLKFBIN of the MMCM. The MMCM continually adjusts to ensure that the CLKIN and CLKFBIN remain in phase, thus cancelling out the delay through the BUFG and its associated clock network (with some fudge factor in certain cases).

Since all BUFG (and derivatives BUFGMUX, BUFGCE, BUFGCTRL) all have essentially the same delay, the adjustment to keep CLKIN and CLKFBIN in phase effectively cancels out the delay of any output of the MMCM that goes through a BUFG type cell and network.

Avrum
0 Kudos