Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

better ways to clock divisions

Status
Not open for further replies.

bharath9

Newbie level 3
Newbie level 3
Joined
Dec 17, 2014
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Visit site
Activity points
22
hey guys,

which is better way to divide the clock either using pll(ip's) or writing code algorithm.
when to use pll?
when to use algorithm?
 

we can also divide using counter logic but when to use counter logic?
 

You use counter logic for example when you need a clock enable. And of course you never ever use the counter output directly as a clock signal, because that would be silly. But you would of course never even think of using the counter output as a clock signal, right? ;-)

- - - Updated - - -

A PLL is always the safest way.

Never say always, never say ne ... ah crap.

Or rather, PLL is not always the safest way to clock logic at a divided clock frequency. Let's say your main clock is 200 MHz. And some stuff needs to run at 50 MHz. Okay, you could use a PLL and divide that 200 MHz by 4, and then use that 50 MHz clock for the low frequency part of the design. Buuuut, the moment you have to pass data between the 50 MHz and the 200 MHz part of the design ... clock domain crossing with all the fun that goes with that. If on the other hand you use a clock enable that is enabled 1 out of 4 cycles, you can keep everything in the 200 MHz clock domain, and still have the slow part run at 50 MHz.
 
Or rather, PLL is not always the safest way to clock logic at a divided clock frequency. Let's say your main clock is 200 MHz. And some stuff needs to run at 50 MHz. Okay, you could use a PLL and divide that 200 MHz by 4, and then use that 50 MHz clock for the low frequency part of the design. Buuuut, the moment you have to pass data between the 50 MHz and the 200 MHz part of the design ... clock domain crossing with all the fun that goes with that. If on the other hand you use a clock enable that is enabled 1 out of 4 cycles, you can keep everything in the 200 MHz clock domain, and still have the slow part run at 50 MHz.

Well both Altera and Xilinx tools do very well with related clocks such as this example 200 MHz & 50 MHz. If the relationship between the clocks are not severed by something like false path or an asynchronous switch then the tools will analyze the timing paths between the clock domains as if they were synchronous, which they are (if you're smart and use two PLL outputs that are 200 MHz and 50 MHz).

Now if you intended to specify clocks that are generated by the PLL but are pretty much asynchronous due to clock edges that don't line up with the faster clock (e.g. 200 MHz and 66.67 MHz) then that would be an issue.

I have also dealt with cases where you have a 200 MHz input clock, but you run only a tiny fraction of the logic at that frequency (memory interface) and the rest of the design runs at 50 MHz. So it makes more sense in that case to use a PLL (with 200 MHz and 50 MHz outputs) than to run the entire clock network at 200 MHz and then also have to run an enable (over a global clock) to every single register in the design, just so you can have a single clock domain.

Note: I've suggested a global clock for the enable, because there is no way to drive 100,000 flip flop enables (<25% of the FFs in a XC7K325T) using local routing and expect it to make 50 MHz. Besides using up that much local routing resources would be a huge problem, which is also why it's bad to use a reset on every single FF in a design.
 
@ads-ee. When you say global clock enable, how would that be implemented? lets take example of Altera. Altera may have some sort of megafunction that is basically a clock enable block and maps to an actual clock enable block on the silicon. After this, there are flip flop primitives in the Altera library that have an enable input. I assume that these enable inputs can be used as clock enable.
 

@ads-ee. When you say global clock enable, how would that be implemented? lets take example of Altera. Altera may have some sort of megafunction that is basically a clock enable block and maps to an actual clock enable block on the silicon. After this, there are flip flop primitives in the Altera library that have an enable input. I assume that these enable inputs can be used as clock enable.

I'm not talking about some special megafunction or primitive.

Just some code like this:
Code:
always @ (posedge clk_200m) begin
  if (ena_50m) begin
    a_slow_update_register <= d_input;
  end
end
Both Altera and Xilinx allow the use of a global clock buffer to be used for high fan out nets. i.e. if you have every register in a design getting the same clock enable (e.g.: running logic at 50 MHz using a 200 MHz system clock), then you would likely find that the place and route tool puts that clock enable on a global clock buffer.
 
The PLLs will be device specific and you will need to consult the individual chip implementation for that. The Code to divide a clock will be independent of it and solves some issue as synchronization. However, for high clock frequency they will generate a large amount of jitter. If you wish to check clock dividers using verilog code, you may check examples here . For device specific refer to the datasheets and tools of the respective vendor.
 

The PLLs will be device specific and you will need to consult the individual chip implementation for that. The Code to divide a clock will be independent of it and solves some issue as synchronization. However, for high clock frequency they will generate a large amount of jitter. If you wish to check clock dividers using verilog code, you may check examples here . For device specific refer to the datasheets and tools of the respective vendor.

These clock dividers are the same as the bad practice mentioned above. Not only do they suffer from jitter, they are very prone to p&r timing and PVT. Logic clock deviders should be avoided at ALL COSTS in an FPGA.

Much better to generate clock enables, or if you need an actual clock - use a PLL.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top