the clock divider with enable using verilog

Hi,

use a counter running continuously on your 50MHz clk from 0 to 49 and back.

generate a single enable pulse when count say = 49. Enable should be low otherwise. Then use this enable pulse together with your 50MHz clk to enable your work at 1MHz.

Additionally, you may add a multicycle of 50 to your logic timing constraints since the required speed is now just 1MHz. Obviously, you don't need to do this if your design doesn't violate the 50MHz.

Regards

kaz

--- Quote Start ---

Hi,

use a counter running continuously on your 50MHz clk from 0 to 49 and back.

generate a single enable pulse when count say = 49. Enable should be low otherwise. Then use this enable pulse together with your 50MHz clk to enable your work at 1MHz.

Additionally, you may add a multicycle of 50 to your logic timing constraints since the required speed is now just 1MHz. Obviously, you don't need to do this if your design doesn't violate the 50MHz.

Regards

kaz

--- Quote End ---

In accordance with your post, I wrote the following code,could tell me is it right?is it the enable clock divider? THX very much.

module divider

(clk,

rst_n,

clk_o);

parameter TIMECONST_49 = 6'b110001;

input clk;

input rst_n;

output reg clk_o;

reg [5:0] div_50;

reg en_50;

always @ (posedge clk or negedge rst_n)

begin

if (!rst_n)

begin

div_50 <= 6'b000000;

en_50 <= 1'b0;

end

else

begin

if (div_50 == TIMECONST_49)

begin

div_50 <= 6'b000000;

en_50 <= 1'b1;

end

else

begin

div_50 <= div_50 + 6'b1;

en_50 <= 1'b0;

end

end

end

always @ (posedge clk or negedge rst_n)

begin

if (!rst_n)

begin

clk_o <= 1'b0;

end

else if (en_50)

clk_o <= ~clk_o;

end

endmodule

--- Quote Start ---

In accordance with your post, I wrote the following code,could tell me is it right?is it the enable clock divider? THX very much.

module divider

(clk,

rst_n,

clk_o);

parameter TIMECONST_49 = 6'b110001;

input clk;

input rst_n;

output reg clk_o;

reg [5:0] div_50;

reg en_50;

always @ (posedge clk or negedge rst_n)

begin

if (!rst_n)

begin

div_50 <= 6'b000000;

en_50 <= 1'b0;

end

else

begin

if (div_50 == TIMECONST_49)

begin

div_50 <= 6'b000000;

en_50 <= 1'b1;

end

else

begin

div_50 <= div_50 + 6'b1;

en_50 <= 1'b0;

end

end

end

always @ (posedge clk or negedge rst_n)

begin

if (!rst_n)

begin

clk_o <= 1'b0;

end

else if (en_50)

clk_o <= ~clk_o;

end

endmodule

--- Quote End ---

Hi simplorer,

the signal is intended to be used as enable for for the FF's.

e.g:

always @(posedge clk) begin

if (enable) ff_sig <= in;

end

Hi,

yes indeed, every FF is to be clocked by the 50MHz as usual but every FF meant to run at 1MHz needs the enable signal as well. This enable signal in a good compiler should be wired up to the enable port of the FF.The compiler infers that from the location of the signal construct(not its name!, you may even insert your construct directly instead of explicit signal).

There are also certain pitfalls when using enable. In particular be careful about the logic level of any signal when enable is inactive, you may have to freeze it or deactivate it depending on the design.

It is well-known that cascaded enable in multi-module systems is prone to bugs and needs extra care.

But overall, it is excellent from timing perspective, though some may argue that it means more power.

Kaz

--- Quote Start ---

Hi,

yes indeed, every FF is to be clocked by the 50MHz as usual but every FF meant to run at 1MHz needs the enable signal as well. This enable signal in a good compiler should be wired up to the enable port of the FF.The compiler infers that from the location of the signal construct(not its name!, you may even insert your construct directly instead of explicit signal).

There are also certain pitfalls when using enable. In particular be careful about the logic level of any signal when enable is inactive, you may have to freeze it or deactivate it depending on the design.

It is well-known that cascaded enable in multi-module systems is prone to bugs and needs extra care.

But overall, it is excellent from timing perspective, though some may argue that it means more power.

Kaz

--- Quote End ---

hi,Kaz,thx.I come from china and my english is poor,so i can not understand

you completely,could you post some codes using verilog,even very simply, i think the code is the best language that we can kown each other&#12290;

thank again&#65281;

Hi simplora(nee ha),

I believe your counter code is correct.

As to enable, the code from pletz explains it well for the given assignment.

I am sorry I haven't use verilog for quite sometime(I used it in 2004/006 and can't remeber...). I know vhdl more than my mother language. If you wish I can do that in vhdl...

regards

Kaz

--- Quote Start ---

Hi simplora(nee ha),

I believe your counter code is correct.

As to enable, the code from pletz explains it well for the given assignment.

I am sorry I haven't use verilog for quite sometime(I used it in 2004/006 and can't remeber...). I know vhdl more than my mother language. If you wish I can do that in vhdl...

regards

Kaz

--- Quote End ---

hi,i do not know the VHDL,but i can compiler the VHDL code,and i think the RTL is simple,so please post some VHDL code which can be compilered,and another question:

how can i understand "pin to pin delay", i compiler the code i posted above,and do the time simulation,i find the delay is about 12ns between

clock rising edge and the clk_o,i don't know where the delay comes from?

THX!

H simplora,

try the code below

as to pin-t0-pin delay. This is natural and is defined as the delay of combinatorial elements from an input pin to output pin. It is not much relevant in your case as you are not going to use clk_o as an external pin...

-- prbs generator

library IEEE;

use IEEE.std_logic_1164.all;

entity prbs_generator is

port(

reset : in std_logic;

clk : in std_logic;

enable : in std_logic;

data : out std_logic_vector(23 downto 0)

);

end entity prbs_generator;

architecture rtl of prbs_generator is

signal shift_reg : std_logic_vector(33 downto 1);

begin

process(reset, clk)

begin

if(reset = '1')then

shift_reg <= '0' & x"28EA5CB1"; -- seed value

data <= (others => '0');

elsif(rising_edge(clk))then

if(enable = '1')then

-- prbs generator

shift_reg(1) <= shift_reg(33) xor shift_reg(20);

shift_reg(33 downto 2) <= shift_reg(32 downto 1);

-- output

data <= shift_reg(24 downto 1);

end if;

end if;

end process;

end architecture rtl;

--- Quote Start ---

H simplora,

try the code below

as to pin-t0-pin delay. This is natural and is defined as the delay of combinatorial elements from an input pin to output pin. It is not much relevant in your case as you are not going to use clk_o as an external pin...

-- prbs generator

library IEEE;

use IEEE.std_logic_1164.all;

entity prbs_generator is

port(

reset : in std_logic;

clk : in std_logic;

enable : in std_logic;

data : out std_logic_vector(23 downto 0)

);

end entity prbs_generator;

architecture rtl of prbs_generator is

signal shift_reg : std_logic_vector(33 downto 1);

begin

process(reset, clk)

begin

if(reset = '1')then

shift_reg <= '0' & x"28EA5CB1"; -- seed value

data <= (others => '0');

elsif(rising_edge(clk))then

if(enable = '1')then

-- prbs generator

shift_reg(1) <= shift_reg(33) xor shift_reg(20);

shift_reg(33 downto 2) <= shift_reg(32 downto 1);

-- output

data <= shift_reg(24 downto 1);

end if;

end if;

end process;

end architecture rtl;

--- Quote End ---

thx again.i code s simple AND gate,like: out1 = in1 & in2,i found the out1 is delay about 6ns to in1 and in2,how to explain this.

Hi simplora,

You will always get some delay that is made up of:

- input pin to gate(routing)

- gate delay

- gate to output pin(routing).

The delay varies from device to device and by the way cplds are very fast in this respect because FPGAs have too much of routing garbage. Moreover, the fpga doesn't actually use simple AND gate but a LUT??

Kaz