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!

Reply

using two BUFR in series to attain a slower clock rate

Accepted Solution Solved
Highlighted
Explorer
Posts: 110
Registered: ‎05-14-2017
Accepted Solution

using two BUFR in series to attain a slower clock rate

My MMCM cannot generate a slow clock, the slowest is 4Mhz. therefore currently the input to the MMCM is 125Mhz and one of the output is 5Mhz.I need a 200khz clock.

One BUFR with a maximum of divide by 8 produce 625KHZ.

Can I tie the 625khz output to another BUFR and divide by 4 to generate 156Khz?

 

 

 

 

 


Accepted Solutions
Instructor
Posts: 3,631
Registered: ‎01-23-2009

Re: using two BUFR in series to attain a slower clock rate

I thought using Xilinx clock buffer, BUFR would allow one to use the fast dedicated clock resources and get less skew on the clock line.

Not that it really matters at this frequency, but you can still put a BUFR on the clk_out.

 

Clock skew always matters - it affects both the setup check and the hold check.

 

At slow frequencies, the impact on the setup check is not significant - losing a few hundred picoseconds on a several hundred nanosecond path isn't significant.

 

However, for the hold check, the clock skew is significant at all frequencies. Having clock skew creates hold time violations that the tools need to fix by inserting routing, which takes FPGA resources and run time (and consumes power, and...)

 

So, it is always better to have a clock - even a slow clock - on a clock network.

 

Avrum

View solution in original post


All Replies
Moderator
Posts: 8,401
Registered: ‎02-27-2008

Re: using two BUFR in series to attain a slower clock rate

yes,

 

Or, just use DFF to divide the clock (this slow you do not need the BUFR resource).

Austin Lesea
Principal Engineer
Xilinx San Jose
Voyager
Posts: 1,440
Registered: ‎06-24-2013

Re: using two BUFR in series to attain a slower clock rate

Hey @tchin123,

 

Something like this should work just fine ...

signal clk_out : std_logic := '0';
...

clk_proc : process (clk_in) variable cnt_v : natural range 0 to 24 := 0; begin if rising_edge(clk_in) then if cnt_v = 24 then clk_out <= not clk_out; cnt_v := 0; else cnt_v := cnt_v + 1; end if; end if; end process;

... note that you want to use an input clock which is an even multiple of the desired output clock to achieve 50% duty cycle.

 

Hope this helps,

Herbert

-------------- Yes, I do this for fun!
Xilinx Employee
Posts: 555
Registered: ‎10-11-2007

Re: using two BUFR in series to attain a slower clock rate

Actually, not true that the MMCM can not produce a KHz output frequency, You can cascade CLKOUT6 into CLKOUT4 counter via the  CLKOUT4_CASCADE attribute. That gives you two 128 bit counters in series instead of just one. So divide your VCO frequency by 16384 and that will give you the minimum output frequency possible. If the VCO was running at say 600MHz then that is 36.6KHz.

Xilinx Employee
Posts: 555
Registered: ‎10-11-2007

Re: using two BUFR in series to attain a slower clock rate

Forgot. If you can use a BUFGCE then it's possible to divide down the effective frequency using the CE pin. But the duty cycle won't be 50/50. 

Explorer
Posts: 110
Registered: ‎05-14-2017

Re: using two BUFR in series to attain a slower clock rate

Since the desire slow clock (156khz)  is use to drive many LUT and DFF, I thought using Xilinx clock buffer, BUFR would allow one to use the fast dedicated clock resources and get less skew on the clock line. That is why I want to avoid the large divider instead.

 

As for the MMCM, not sure if I can get anything slower than 4Mhz because the Wizard won't allow anything smaller than this.

 

Voyager
Posts: 1,440
Registered: ‎06-24-2013

Re: using two BUFR in series to attain a slower clock rate

Hey @tchin123,

 

I thought using Xilinx clock buffer, BUFR would allow one to use the fast dedicated clock resources and get less skew on the clock line.

Not that it really matters at this frequency, but you can still put a BUFR on the clk_out.

 

Best,

Herbert

-------------- Yes, I do this for fun!
Xilinx Employee
Posts: 555
Registered: ‎10-11-2007

Re: using two BUFR in series to attain a slower clock rate

1) If you want the clock to drive clocking points in the FPGA use a BUFG (or BUFGCE/BUGCNTRL). BUFR limits which and how many clock regions you can reach. I highly recommend you read UG472 Clocking Guide before you proceed any further.

 

https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf

 

2) If you use the Vivado clocking wizard then check the CLKOUT4_CASCADE box under the MMCM Settings tap. Can't remember if it was the same in ISE. Or simply hand edit the Wizard hdl output.

Instructor
Posts: 3,631
Registered: ‎01-23-2009

Re: using two BUFR in series to attain a slower clock rate

Do not use the BUFR for this purpose. The BUFR is intended to divide an I/O clock and is situated in the I/O region of the FPGA (not the global clock region of the FPGA). If you use the BUFR, then the output of the BUFR will not have the same phase as the output of the MMCM due to all the routing back and forth and the buffering.

 

The best way to do this is to use a BUFGCE and enable it only on every Nth clock. Take a look at this post on using the BUFGCE.

 

Avrum

Instructor
Posts: 3,631
Registered: ‎01-23-2009

Re: using two BUFR in series to attain a slower clock rate

I thought using Xilinx clock buffer, BUFR would allow one to use the fast dedicated clock resources and get less skew on the clock line.

Not that it really matters at this frequency, but you can still put a BUFR on the clk_out.

 

Clock skew always matters - it affects both the setup check and the hold check.

 

At slow frequencies, the impact on the setup check is not significant - losing a few hundred picoseconds on a several hundred nanosecond path isn't significant.

 

However, for the hold check, the clock skew is significant at all frequencies. Having clock skew creates hold time violations that the tools need to fix by inserting routing, which takes FPGA resources and run time (and consumes power, and...)

 

So, it is always better to have a clock - even a slow clock - on a clock network.

 

Avrum