cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
17,170 Views
Registered: ‎08-26-2014

FPGA clock gating implementation

Jump to solution

Hello,

 

I´m doing ASIC prototyping on a Virtex7 FPGA. There is one main clock that supplies the design. This main clock (from a PLL) is split into two clocks - one that´s always running and one with a clock gate. This is to turn off some parts of the design to save power.

So, it roughly looks like this:

cpu_clk = main_pll_clk_out;

gated_cpu_clk = main_pll_clk_out & enable;

 

What would be the best way to model this in the FPGA?

I came up with two ideas and would like to ask for some feedback if this is going in the right direction.

 

The PLL is modeled by a MMCM, and one approach would be to use a BUFG after it for the cpu_clk and connect a BUFGCE to it in parallel for the gated_cpu_clk.

So this would look like this:

MMCME2(
   .CLKOUT0(mmcm_output),     // 1-bit output: CLKOUT0 
);

BUFG clk_buf_p_i0 ( 
   .I(mmcm_output), 
   .O(cpu_clk) 
);


BUFGCE bufgce_i0 (   
   .I(mmcm_output),
   .CE(enable),
   .O(gated_cpu_clk)    
);

 

A slightly different approach would be using one global and one regional buffer instead of the two global buffers like above.

 

MMCME2(
   .CLKOUT0(mmcm_output),     // 1-bit output: CLKOUT0 
);

BUFG clk_buf_p_i0 ( 
   .I(mmcm_output), 
   .O(cpu_clk) 
);


BUFHCE bufhce_i0 (      
   .I(cpu_clk),
   .CE(enable),
   .O(gated_cpu_clk)    
);

Here, the signal goes from the MMCM to the BUFG, and then from the BUFG into a BUFHCE which can be disabled.

 

Is it a good idea to model the clock gates like this? Or do you have any other recommentations?

Are these approaches the more FPGA friendly ones or should I just instantiate a MMCM and use verilog code (like in the very first box) to model the clock gate and let the tool do a gated clock conversion?

 

Thank you for your input.

Antonio 

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
27,547 Views
Registered: ‎01-23-2009

Antonio,

 

Both of these are correct, and are the only way you should consider doing clock gating.

 

The disadvantage of the BUFHCE is that the output clock is restricted to one clock region. Depending on you device, this is a small fraction of the overall device. Unless the loads driven by the gated clock are small in number, I would recommend the BUFGCE - especially since there is only one gated domain.

 

The only reason not to use the BUFGCE is if you run out of global clock buffers. If these really are the only two domains in your system, then you should definitely use the BUFGCE.

 

The only thing to watch out for is the timing of the enable. The CE has a setup time requirement to the rising edge of the input clock to the BUFGCE. This generally means that the gating logic has to be running on an un-gated version of the same clock (which is your "cpu_clk"). Also be aware that the enable will effectively gate the next clock, which (depending on how your enable is generated in the ASIC), may be the clock after the first clock that would be gated in the ASIC.

 

Avrum

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
17,164 Views
Registered: ‎02-16-2014
0 Kudos
Highlighted
Guide
Guide
27,548 Views
Registered: ‎01-23-2009

Antonio,

 

Both of these are correct, and are the only way you should consider doing clock gating.

 

The disadvantage of the BUFHCE is that the output clock is restricted to one clock region. Depending on you device, this is a small fraction of the overall device. Unless the loads driven by the gated clock are small in number, I would recommend the BUFGCE - especially since there is only one gated domain.

 

The only reason not to use the BUFGCE is if you run out of global clock buffers. If these really are the only two domains in your system, then you should definitely use the BUFGCE.

 

The only thing to watch out for is the timing of the enable. The CE has a setup time requirement to the rising edge of the input clock to the BUFGCE. This generally means that the gating logic has to be running on an un-gated version of the same clock (which is your "cpu_clk"). Also be aware that the enable will effectively gate the next clock, which (depending on how your enable is generated in the ASIC), may be the clock after the first clock that would be gated in the ASIC.

 

Avrum

View solution in original post

Highlighted
Contributor
Contributor
17,126 Views
Registered: ‎08-26-2014

Hi Avrum,

 

thank you for your detailed explanation. In that case I´ll go with the BUFGCE implementation.

 

Well yes, you´re right - I guess you already suspected more than one clock for ASIC prototyping. There are actually more than two clocks. But in total it´s about ten, so I´m not too concerned about running out of clocking resources. The two I mentioned are the main clocks for the processor core.

 

It´s very helpful what you mentioned in the last paragraph.

About the setup timing requirement: cpu_clk drives the processor core and this is generating the enable signal for gated_cpu_clk. Basically, the processor core can turn off a part of itself. As you pointed out, this should be fine like this.

 

I think it´s not really a problem if there´s one additional clock cycle before the enable goes away. I´ll do a simulation on that to make sure.

 

Thanks again.  

Antonio   

 

 

 

0 Kudos