This would not give what Alexis wants.
module and_clk (
input wire clk,
input wire rst_n,
input wire enable,
output reg cond
);
always @(posedge clk or negedge rst_n)
begin
if(~rst_n) begin
cond <= 1'b0;
end else begin
cond <= enable & clk;
end
end
endmodule
As the FF captures a data only on posedge of clock, cond <= enable & clk will always put 1'b1 in cond(when enable is high btw).
I can see two solutions to do what you want :
Add logic in the clock (which can result in serious problems in synthesis)
module and_clk (
input wire clk,
input wire rst_n,
input wire enable,
output wire cond
);
reg enable_q;
always @(posedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_q <= 1'b0;
end else begin
enable_q <= enable;//stores enable value in a FF
end
end
assign cond = enable_q & clk; //it is not safe to add combinatorial cells on the clock path. It will complicate the generation of the clock tree
endmodule
Use a negedge triggered FF, a bit more complicated but much more safe for synthesis
module and_clk (
input wire clk,
input wire rst_n,
input wire enable,
output wire cond
);
reg enable_q;
always @(posedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_q <= 1'b0;
end else begin
enable_q <= enable & ~enable_qn;//stores enable value in a FF
//set to 0 when enable_qn is high to generate the cycles you want
end
end
always @(negedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_qn <= 1'b0;
end else begin
enable_qn <= enable_q;
//will take the value of enable_q half a cycle later
end
end
assign cond = enable_q ^ enable_qn;
//xoring the output will give you what you want
endmodule
Not a so simple question finally :)
EDIT:
Issues about adding logic on clock path:
Adding logic on clock path adds two things:
- Delay to the output of the logic: which can create metastability as the resulting signal will certainly change in a close window of the clock edges. (This site explains quite clearly the problem of metastability)
- Capacitance to the input: This results in unbalancing the clock tree i.e. ruining the work that the synthesis tool made to ensure that all FF, with the same clock, are triggered at the same time.(This ppt explains how a clock tree is generated)
This interesting pdf regroups a bunch of things that should be avoided to design reliable circuits.
Issues about adding enable in the output path:
(To understand what I will try to explain in the next lines, you have to carefully read, and understand, my first reference)
I do not know from where your enable signal comes but as your drawn it seems to be asynchronous. The issue with asynchronous signals in synchronous designs is that they can violate the setup/hold constraints of the FF and then create metastability which will results in unpredictable value of the output FF which constraints had been violated.
If you understood the article about metastability, you should have figured that even putting enable in enable_q can create metastability. To be (more) covered about that, one solution is to add a negedge triggered FF "between" enable and enable_q.
As it is a matter of probability metastability can occur everywhere. A safer version of you design would be:
module and_clk (
input wire clk,
input wire rst_n,
input wire enable,
output wire cond
);
reg enable_q, enable_meta;
//This FF store on negedge the value of enable
always @(negedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_meta <= 1'b0;
end else begin
enable_meta <= enable;//stores enable value in a FF
end
end
//By doubling this FF the risk of metastability is greatly reduced
always @(posedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_q <= 1'b0;
end else begin
enable_q <= enable_meta & ~enable_qn;//stores enable value in a FF
//set to 0 when enable_qn is high to generate the cycles you want
end
end
always @(negedge clk or negedge rst_n)
begin
if(~rst_n) begin
enable_qn <= 1'b0;
end else begin
enable_qn <= enable_q;
//will take the value of enable_q half a cycle later
end
end
assign cond = (enable_q ^ enable_qn) & enable_meta;
//adding "& enable_meta" can replace "enable"
//This should be safe as the result of the xor will have a very low probability of metastability
endmodule
This solution will be safer, but also bigger and quite more complicated.
There also will be configurations of event that will lead an extra cycle on cond or a 1 clock cycle delay depending on the rise/fall arrival of enable.
Hope this helps.
