gate control clock generation - verilog

Here is the code first...
always#(posedge clk)
begin
if(cstate==idle) rclk<=1;
else rclk<=0;
end
always#(negedge clk)
rclk<=0;
What I want to achieve is this: every time at the rising edge of clock signal, if the signal cstate equals idle(4'b0000), the the rclk goes to one, else to zero, at the same time, every time the falling edge of clk will set the rclk to zero. THIS CODE IS NOT SYNTHESIZABLE since the compiler gives the error " the rclk signal is driven by multiple drivers".
How can I achieve the same function by other techniques?

It looks like you want a clock gate cell. Based on a 1 cycle wide enable signal generate a clock pulse which has the same high time as the input clock.
A naive way of doing this might be :
assign rclk = (cstate==idle) ? clk : 1'b0 ;
Which could easily be synthesised assign rclk = (cstate==idle) & clk ;
cstate == idle is going to glitch which is why it would normally be used by a flip-flop allowing the answer to settle before being used.
Using a clock gate cell stops you from creating glitches on the (rclk) clock line. It is common to instantiate your libraries clock gate cell in the rtl for this. In RTL it might be similar to :
reg result;
always #(posedge clk or negedge rst_n) begin
if (~rst_n) begin
result <= 1'b0;
end
else begin
result <= (cstate == idle);
end
end
assign rclk = (result) ? clk : 1'b0 ;
This means result will be stable for each clock cycle, not allowing glitches through from the comparator.
Expanded answer
I have included my example again below with waveform, I have replaced your state comparison with a simple counter which overflows to reset itself. Not the comparison is matching to 2'b10; which means the clock appears on the following count (2'b11). If the clock was to appear in exactly the same time your comparison matched then you have no glitch suppression on your clock and will likely generate unreliable hardware.
reg [1:0] counter = 0;
always #(posedge clk)
counter <= counter+1;
reg result;
wire result_a = (counter == 2'b10 );
always #(posedge clk or negedge rst_n) begin
if (~rst_n) begin
result <= 1'b0;
end
else begin
result <= result_a;
end
end
assign rclk = (result) ? clk : 1'b0 ;

Related

Not seeing a clock cycle delay in Vivado simulation during a register/flipflop assignment

I am trying to generate a pulse from a signal ext_sample_clk. My design currently has 2 clock signals, clk and ext_sample_clk, which I am generating through a testbench. The following is my simplified code. Besides this, I also have the clk and reset generation logic, which I have not shown for simplicity. I can share those if needed.
module tb;
reg clk;
reg rst;
reg ext_sample_clk;
reg ext_sample_clk_r1;
wire ext_sample_pulse_orig;
//clock gen logic
always
begin
clk = 1'b1;
#5; // 10 ns
clk = 1'b0;
#5;
end
// reset gen logic
initial
begin
rst = 1;
#(100);
rst = 0;
end
// ext_sample_clk logic
always
begin
ext_sample_clk = 1'b1;
#50;
ext_sample_clk = 1'b0;
#50;
end
// register the ext_sample_clk logic, should infer a flip flop
always #(posedge clk) begin
if (rst)
ext_sample_clk_r1 <= 0;
else
ext_sample_clk_r1 <= ext_sample_clk; // lhs doesn't appear to be delayed by 1 clock cycle wrt to rhs
end
assign ext_sample_pulse_orig = ext_sample_clk && !ext_sample_clk_r1;
endmodule
I am expecting to see ext_sample_clk_r1 delayed by one clock pulse compared to ext_sample_clk. But the following is what I observe when I run a simulation on Vivado.
Can anyone explain why I am not seeing a clock cycle delay in ext_sample_clk_r1 with reference to ext_sample_clk. Am I missing something ?
Since you want ext_sample_clk_r1 and ext_sample_clk to be synchronous to the same clock (clk), you need to drive them both off of posedge clk, using nonblocking assignments (<=):
initial begin
ext_sample_clk = 1'b1;
forever begin
repeat (10) #(posedge clk);
ext_sample_clk <= ~ext_sample_clk;
end
end
Here is a running example on edaplayground.
The most probably way of getting the results you see is by using a blocking assignment to ext_sample_clk instead of a non-blocking assignment. Your testbench needs to follow the same rules as if it were part of the design to avoid race conditions. Use a non-blocking assignment or have your testbench apply signals on the opposite edge.

Timers and LEDs in Verilog

I have a question about using timers and clocks in Verilog. I want to set up a custom reg to compare to an accumulator, which will control the state of an LED. The board uses inverse logic, so 0 is high on the LED. There are a few concepts I just need some clarification on. The clock is 100 MHz.
always #(posedge clk100 or negedge reset_)
begin
cust_LED_counter <= (cust_LED_counter<cust_LED_timer) ? cust_LED_counter + 1'b1 : 16'd0;
cust_LED_timer1 <= (cust_LED_counter == cust_LED_timer);
if(!reset_)
begin
cust_LED1 <= 'b0;
cust_LED_timer <= 'd0;
cust_LED_timer1 <= 'd0;
end
else
begin
cust_LED1 <= ~cust_LED_timer1;
end
end
For the accumulator, what is the action that resets it and allows for blinking to happen? Would it not hit the cust_LED_timer value and stay at that high reading?
I think I'm misunderstanding how a FPGA clock operates. Assuming this would cause a blinking action in the LED, it would mean some timer hit the upper limit and reset; however, I'm not sure if this would take place in the counter portion of the code, or instead would occur where the clock/reset is defined.
Also, based on how this layout looks it wouldn't be a uniform blink, in terms of equal time on and off. Is there a way to implement such a system for custom input?
Here's a simple module that should blink the LED with a 50-50 duty cycle for an arbitrary number of clocks (up to 2^26)
module blink(input clk, input rst, input [25:0] count_max, output LED);
reg [25:0] counter, next_count;
assign LED = counter < count_max >> 1;
always #(posedge clk or posedge rst)
begin
if (rst)
counter <= 0;
else
counter <= next_count;
end
always #* begin
if (counter < count_max - 1)
next_count = counter + 1;
else
next_count = 0;
end
endmodule // blink
Let me know if this doesn't compile! I don't have a verilog compiler where I'm writing this from at the moment!

A simple clock divider module

I am asked to design simple clock divider circuit for different types of inputs.
I have a enabler [1:0] input and an input clock, and an output named clk_enable.
If enabler=01 then my input clock should be enabled once in 2 clock signals.If enabler=10 then my input should be divided by 4 etc.
I managed to divide my input clock for different cases with using case keyword but for enabler=00 my input clock should be equal to my output clk_enable which i could not manage to do it.
Here is what i tried. I am asking a help for the enabler=00 situation.
module project(input [1:0] enabler,
input clock,
output reg clk_enable);
reg [3:0] count,c;
initial begin
count=4'b0000;
c=4'b0000;
end
always #( posedge clock)
case(enabler)
2'b00:clk_enable<=clock;
2'b01:clk_enable<=~clk_enable;
2'b10:begin
if (count >= 4'b0100-1)
count<=4'b0000;
else begin
count<=count + 4'b0001;
clk_enable<=(count<(4'b0100 / 2));
end
end
2'b11: begin
if (count >= 4'b1000-1)
count<=4'b0000;
else begin
count<=count + 4'b0001;
clk_enable<=(count<(4'b1000 / 2));
end
end
endcase
endmodule
This will generate gated pulsed clock with posedge rate matching the div_ratio input.
div_ratio output
0 div1 clock (clk as it is)
1 div2 (pulse every 2 pulses of clk)
2 div3
3 div4
This is usually preferable when sampling at negedge of divided clock is not needed
If you need 50% duty cycle I can give you another snippet
module clk_div_gated (
input [1:0] div_ratio,
input clk,
input rst_n, // async reset - a must for clock divider
output clk_div
);
reg [1:0] cnt;
reg clk_en;
always #(posedge clk or negedge rst_n)
if (~rst_n)
cnt <= 2'h0;
else
cnt <= (cnt == div_ratio)? 2'h0 : cnt + 1'b1;
// clk_en toggled at negedge to prevent glitches on output clock
// This is ok for FPGA, synthesizeable ASIC design must use latch + AND method
always #(negedge clk)
clk_en <= (cnt == div_ratio);
assign clk_div <= clk & clk_en;
endmodule
This looks like you have a strong background in software development? :)
My suggestion is that you always make a clean cut between combinational and sequential logic. This includes some thoughts on what part of the design actually has to be sequential and what can be combinational.
For your case, the clock division clearly has to be sequential, since you want to invert the generated CLK signal (frequency f/2, case 0'b01) at each positive edge of the incoming CLK signal (frequency f, case 0'b00). Same is valid for f/4 (case 0'b10).
This part needs to be sequential, since you want to invert the previous CLK state...this would cause a cmobinational loop if realized in combinational logic. So triggering on a CLK edge is really necessary here.
However, the actual selection of the correct CLK output signal can be combinational. You just want to assign the correct CLK signal to the output CLK.
An implementation of the sequential part could look like:
// frequency division from input CLK --> frequency: f/2
always #(posedge clk or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_2 <= 1'b0;
end else begin
clk_2 <= ~clk_2;
end
end
// frequency division from first divided CLK --> frequency: f/4
always #(posedge clk_2 or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_ 4 <= 1'b0;
end else begin
clk_4 <= ~clk_4;
end
end
// frequency division from first divided CLK --> frequency: f/8
always #(posedge clk_4 or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_ 8 <= 1'b0;
end else begin
clk_8 <= ~clk_8;
end
end
So this plain sequential logic takes care of generating the divided CLK signals of f/2 and f/4 that you need. I also included reset signals on negative edge, which you usually need. And you spare the counter logic (increments and comparison).
Now we take care of the correct selection with plain combinational logic:
always #(*) begin
case(enabler)
2'b00: clk_enable = clk;
2'b01: clk_enable = clk_2;
2'b10: clk_enable = clk_4;
2'b11: clk_enable = clk_8;
endcase
end
This is quite close to your hardware description (clk_enable needs to be a reg here).
However, another way for the combinational part would be the following (declare clk_enable as wire):
assign clk_enable = (enabler == 2'b00) ? clk
: (enabler == 2'b01) ? clk_2
: (enabler == 2'b10) ? clk_4
: (enabler == 2'b11) ? clk_8;

Shortests version to choose posedge/negedge sensitivity from module parameter?

I want to build a Verilog module so that the user can select the sensitivity of some input clock signal by a module parameter. As an example, I wrote the following counter which can either count up on posedge or negedge selected by parameter clockEdge.
module Counter (clk, reset, value);
parameter clockEdge = 1; // react to rising edge by default
input clk;
input reset;
output reg [7:0] value;
generate
if(clockEdge == 1) begin
always #(posedge clk or posedge reset) begin
if (reset) begin
value <= 0;
end else begin
value <= value + 1;
end
end
end else begin
always #(negedge clk or posedge reset) begin
if (reset) begin
value <= 0;
end else begin
value <= value + 1;
end
end
end
endgenerate
endmodule
This principle is working, however I don't like that the implementation is basically copy and paste for both variants. What would be a shorter version without duplication?
Simplest is to invert the clock with an exor gate. Then use that clock in an always section:
wire user_clock;
assign user_clock = clk ^ falling_edge;
always #(posedge user_clock) // or posedge/negedge reset/_n etc.
test_signal <= ~ test_signal;
If falling_edge is 0 then user_clock and clk have the same polarity and the data is clocked at nearly the same time as you have a rising edge of clk.
If falling_edge is 1 then user_clock and clk have the opposite polarity and the data is clocked nearly the same time as the falling edge of clk.
Be careful when you change the polarity of falling_edge as it can generate runt clock pulses! Safest is to use a gated clock: stop the clock, switch polarity, then start it again.
In both cases user_clock will lag the system clk by small amount. The amount depends on the delay of the exor-gate.
Here is a simulation+:
+test_signal was set to zero in an initial statement.
I think that cut-n-paste in this tiny example is ok, though verilog has some instruments to make it easier for more complicated cases, namely functions and macros. You can use them as well, i.e.
function newValue(input reset, input reg[7:0] oldValue);
if (reset) begin
newValue = 0;
end else begin
newValue = value + 1;
end
endfunction
generate
if(clockEdge == 1) begin
always #(posedge clk or posedge reset) begin
value <= newValue(reset, value);
end
end else begin
always #(negedge clk or posedge reset) begin
value <= newValue(reset, value);
end
end
endgenerate
the other possibility is to use macros with or without paramenters. Methodology-wise macros are usually worse than functions, though here is an extreme example, though in my opinion it makes the code less readable and could have issues with debugging tools.
`define NEW_VALUE(clk_edge) \
always #(clk_edge clk or posedge reset) begin\
if (reset) begin\
value <= 0;\
end else begin\
value <= value + 1;\
end\
end
generate
if(clockEdge == 1) begin
`NEW_VALUE(posedge)
end else begin
`NEW_VALUE(negedge)
end
endgenerate
Implementing custom clock reg that follows posedge or negedge of clk might be one way to do it. This seems to work well on my machine :)
reg myclk;
always#(clk) begin
if(clk) begin
myclk = clockEdge? 1 : 0; #1 myclk = 0;
end else begin
myclk = clockEdge? 0 : 1; #1 myclk = 0;
end
end
always#(posedge myclk or posedge reset) begin
if(reset)
cnt <= 0;
else
cnt <= cnt+1;
end

My Verilog behavioral code getting simulated properly but not working as expected on FPGA

I wrote a behavioral program for booth multiplier(radix 2) using state machine concept. I am getting the the results properly during the program simulation using modelsim, but when I port it to fpga (spartan 3) the results are not as expected.
Where have I gone wrong?
module booth_using_statemachine(Mul_A,Mul_B,Mul_Result,clk,reset);
input Mul_A,Mul_B,clk,reset;
output Mul_Result;
wire [7:0] Mul_A,Mul_B;
reg [7:0] Mul_Result;
reg [15:0] R_B;
reg [7:0] R_A;
reg prev;
reg [1:0] state;
reg [3:0] count;
parameter start=1 ,add=2 ,shift=3;
always #(state)
begin
case(state)
start:
begin
R_A <= Mul_A;
R_B <= {8'b00000000,Mul_B};
prev <= 1'b0;
count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add:
begin
case({R_B[0],prev})
2'b00:
begin
prev <= 1'b0;
end
2'b01:
begin
R_B[15:8] <= R_B[15:8] + R_A;
prev <= 1'b0;
end
2'b10:
begin
R_B[15:8] <= R_B[15:8] - R_A;
prev <= 1'b1;
end
2'b11:
begin
prev <=1'b1;
end
endcase
end
shift:
begin
R_B <= {R_B[15],R_B[15:1]};
count <= count + 1;
end
endcase
end
always #(posedge clk or posedge reset)
begin
if(reset==1)
state <= start;
else
begin
case(state)
start:
state <= add;
add:
state <= shift;
shift:
begin
if(count>7)
state <= start;
else
state <=add;
end
endcase
end
end
endmodule
You have an incomplete sensitivity list in your combinational always block. Change:
always #(state)
to:
always #*
This may be synthesizing latches.
Use blocking assignments in your combinational always block. Change <= to =.
Good synthesis and linting tools should warn you about these constructs.
Follow the following checklist if something does work in the simulation but not in reality:
Did you have initialized every register? (yes)
Do you use 2 registers for one working variable that you transfer after each clock (no)
(use for state 2 signals/wires, for example state and state_next and transfer after each clock state_next to state)
A Example for the second point is here, you need the next stage logic, the current state logic and the output logic.
For more informations about how to proper code a FSM for an FPGA see here (go to HDL Coding Techniques -> Basic HDL Coding Techniques)
You've got various problems here.
Your sensitivity list for the first always block is incomplete. You're only looking at state, but there's numerous other signals which need to be in there. If your tools support it, use always #*, which automatically generates the sensitivity list. Change this and your code will start to simulate like it's running on the FPGA.
This is hiding the other problems with the code because it's causing signals to update at the wrong time. You've managed to get your code to work in the simulator, but it's based on a lie. The lie is that R_A, R_B, prev, count & Mul_Result are only dependent on changes in state, but there's more signals which are inputs to that logic.
You've fallen into the trap that the Verilog keyword reg creates registers. It doesn't. I know it's silly, but that's the way it is. What reg means is that it's a variable that can be assigned to from a procedural block. wires can't be assigned to inside a procedural block.
A register is created when you assign something within a clocked procedural block (see footnote), like your state variable. R_A, R_B, prev and count all appear to be holding values across cycles, so need to be registers. I'd change the code like this:
First I'd create a set of next_* variables. These will contain the value we want in each register next clock.
reg [15:0] next_R_B;
reg [7:0] next_R_A;
reg next_prev;
reg [3:0] next_count;
Then I'd change the clocked process to use these:
always #(posedge clk or posedge reset) begin
if(reset==1) begin
state <= start;
R_A <= '0;
R_B <= '0;
prev <= '0;
count <= '0;
end else begin
R_A <= next_R_A;
R_B <= next_R_B;
prev <= next_prev;
count <= next_count;
case (state)
.....
Then finally change the first process to assign to the next_* variables:
always #* begin
next_R_A <= R_A;
next_R_B <= R_B;
next_prev <= prev;
next_count <= count;
case(state)
start: begin
next_R_A <= Mul_A;
next_R_B <= {8'b00000000,Mul_B};
next_prev <= 1'b0;
next_count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add: begin
case({R_B[0],prev})
2'b00: begin
next_prev <= 1'b0;
end
.....
Note:
All registers now have a reset
The next_ value for any register defaults to it's previous value.
next_ values are never read, except for the clocked process
non-next_ values are never written, except in the clocked process.
I also suspect you want Mul_Result to be a wire and have it assign Mul_Result = R_B[7:0]; rather than it being another register that's only updated in the start state, but I'm not sure what you're going for there.
A register is normally a reg, but a reg doesn't have to be a register.

Resources