Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
A PLL is always the safest way.
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.
@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.
always @ (posedge clk_200m) begin
if (ena_50m) begin
a_slow_update_register <= d_input;
end
end
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.