Cannot find why value doesn't jump to expectation in the right time - verilog

I have the following code
module POLY(CLK,RESET_n,IN_VALID,IN,OUT_VALID,OUT);
input CLK,RESET_n,IN_VALID;
input [ 3:0] IN;
output OUT_VALID;
output [12:0] OUT;
reg OUT_VALID;
reg [12:0] OUT;
reg OUT_VALID_w;
reg [12:0] OUT_w;
reg [ 1:0] COUNT_IN, COUNT_IN_w;
reg [ 2:0] COUNT_DO, COUNT_DO_w;
always #(posedge CLK or negedge RESET_n)
begin
if(!RESET_n)
begin
COUNT_IN <= 2'd0;
COUNT_DO <= 3'd0;
end
else
begin
COUNT_IN <= COUNT_IN_w;
COUNT_DO <= COUNT_DO_w;
end
end
always #(*)
begin
if(IN_VALID == 1'b0)
begin
if(COUNT_DO == 3'd7)
begin
COUNT_DO_w = COUNT_DO;
end
else
begin
COUNT_DO_w = COUNT_DO + 1'b1;
end
end
else
begin
COUNT_DO_w = 3'd0;
end
end
I want to ask is that why COUNT_DO doesn't jump to 1 in 14ns?
I think that due to the sensitive list in the second always block is COUNT_DO and IN_VALID,
so at start, the reset signal trigger first always block and set the COUNT_DO = 0, which change the COUNT_DO value from high impedence to 0. So, it triggers the second always block COUNT_DO_w = 0 + 1 = 1. And , in the next postive edge clock, which trigger the first always block to do COUNT_DO <= COUNT_DO_w. But it seems to delay one clock to assign it(22ns). I have tried to figure it out but still cannot, why it delay one clock?
Thx in advance.

At time=14ns, reset is asserted (RESET_N=0), which means COUNT_DO=0 in the 1st always block. At time t=20ns, you release reset and COUNT_DO remains at 0. At time=22ns, you have your 1st posedge CLK which assigns COUNT_DO to COUNT_DO_w. The time at which COUNT_DO changes is controlled only by the 1st always block, not the 2nd.

Related

Execute Always Blocks with same value

I have a simple module that uses a few different states. The Problem I am encountering is say if I want to stay at the same state for multiple clock cycles.
In this case, my current state is synchronous and updates on clock cycle. It executes that always block which goes from state 0 -> state 1. Then once pstate reaches state 1, I attempt to have it wait to reach the next state. The reason for this is to collect data off of the data_int input. I don't care what the data is, but I need to read off it for 2 clock cycles.
I believe this doesn't work however because in the first case, I set the next state to the same value as it previously was, so it is unable to trigger. The reason I don't think I could just also add 'data_int' to the trigger list, is because its possible it remains the same value for a clock cycle and thus the always block wouldn't trigger.
I'm wondering if there is another way to do this, I guess essentially I need the always block to retrigger on clock edge as well..
module TestModule(
input clk, rst, data_int);
reg [2:0] pstate = 0;
reg [2:0] nstate = 0;
ref [2:0] count = 0;
always#(pstate) begin
//only fires when pstate is assigned to a different value?
//would I make a internal clock to constantly have this always run?
if(pstate == 0) begin
nstate <= 1;
end
else if(pstate == 1) begin
//stay at this state for multiple clock cycles
//collect data off of data_int
count = count + 1;
if(count > 2) begin
nstate <= 2;
end else begin
nstate <= 1;
end
end
end
always#(posedge clk, posedge rst) begin
if(rst) begin
pstate <= 0;
end
else begin
pstate <= nstate;
end
end
pay attention to the usage of = and <=.
count is never reset, if you want to enter pstate == 3'h1 state multiple times.
use always#(*) to save your life. synthesis tools will respect the logic inside the always block, but simulation tools won't, which will lead to simulation mismatches.
The following code is based on my understanding of your question.
reg [2:0] pstate;
reg [2:0] nstate;
reg count; // 1-bit 'count' is enough to count 2 cycles
always#(posedge clk or posedge rst)begin
if(rst)begin
pstate <= 3'h0;
end
else begin
pstate <= nstate;
end
end
always#(*)begin
case(pstate)
3'h0: nstate = 3'h1;
3'h1:begin // lasts 2 cycles
if(count)begin
nstate = 3'h2;
end
else begin
nstate = 3'h1;
end
3'h2: (....)
default: (....)
end
endcase
end
always#(posedge clk or posedge rst)begin // 'count' logic
if(rst)begin
count <= 1'h0;
end
else if((pstate == 3'h1) & count)begin // this branch is needed if you don't
// count to the max. value of 'count'
count <= 1'b0;
end
else if(pstate == 3'h1)begin
count <= ~count; // if 'count' is multi-bit, use 'count + 1'
end
end

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

Verilog code, same structure, same style. How come one works but the other doesnt? Where did I go wrong?

I will get straight to the point. I have a simple counter that is trying to
mimic how a clock works pretty much. I have a module called counter60sec and another one called counter12hr
counter12hr
module counter12hr(reset, hourInc, overflowOut, hrCounter);
input reset;
input hourInc;
output overflowOut;
output [3:0] hrCounter;
reg overflowOut;
reg [3:0] hrCounter; //0'b1101 == 13 hours
//Initialize counter
initial begin
overflowOut = 1'b0;
hrCounter = 4'b0; //once hour reaches 12:59:59, it is supposed to go back to zero
end
//Everytime hrInc is one, increment hrCounter
always#(negedge reset or posedge hourInc) begin
overflowOut = 1'b0;
if(reset == 1'b0) begin
overflowOut = 1'b0;
hrCounter = 4'b0;
end
else begin
if (hourInc == 1'b1) begin
hrCounter = hrCounter + 1'b1;
end
end
end
always#(negedge hrCounter) begin
if (hrCounter == 4'b1100) begin
overflowOut = 1'b1;
hrCounter = 4'b0;
end
end
endmodule
counter60sec
module counter60sec(reset, secInc, minOut, secCounter);
input reset;
input secInc;
output minOut;
output [5:0] secCounter;
reg [5:0] secCounter; //0'b111100 == 60 seconds.
reg minOut;
//Initialize counter
initial begin
minOut = 1'b0;
secCounter = 6'b0;
end
//Everytime secInc is one, increment secCounter
always#(posedge secInc or negedge reset) begin
minOut = 1'b0;
if(reset == 1'b0) begin
minOut = 1'b0;
secCounter = 6'b0;
end
else begin
if (secInc == 1'b1) begin
secCounter = secCounter + 1'b1;
end
end
end
//output minOut to 1 to signal minute increase when secCounter hits 111100 in binary
always#(negedge secCounter) begin
if(secCounter == 6'b111100) begin
minOut = 1'b1;
secCounter = 6'b0;
end
end
endmodule
I have test bench set up for both. The counter60sec one works fine (Where when secCounter is at value of 60, the minOut becomes 1). The counter12hr follows the same concept, but the value of overflowOut never becomes 1.
For my hrCounter conditional statement in counter12hr.v, I have tried both 4'b1101 and 4'b1100 and neither of them worked. (Trying to get the overflowOut to become one when the hrCounter hits 13)
I've spent hours on this, taking break to relax my eyes etc. I still can't see where I am going wrong. Any help would be appreciated
you have a few issues. The main one is that you have a multiple-driven register in both cases:
always#(negedge reset or posedge hourInc) begin
overflowOut = 1'b0;
...
always#(negedge hrCounter) begin
if (hrCounter == 4'b1100) begin
overflowOut = 1'b1;
the overflowOut is driven from 2 different alsways blocks. Same as minOut in the second counter. The order in which those statements are executed is undefined and the resulting value would depend on the order.
You need to restructure your program in such a way that the registers are assigned in a single always block only.
Secondly, i think, that you have a logic bug, assigning your overflow to '0' in the first statement of the first block (same as in the second one).
Thirdly, you should have uset non-blocking assighments '<=' in finlal assignments to the registers.
something like the following should work.
always#(negedge reset or posedge hourInc) begin
if(reset == 1'b0) begin
hrCounter <= 4'b0;
overflowOut <= 1'b0;
end
else begin
if (hrCounter == 4'b1100) begin
overflowOut <= 1'b1;
hrCounter <= 4'b0;
end
else
hrCounter <= hrCounter + 1'b1;
overflowOut <= 1'b0;
end
end
end
Your code is wrong in so many ways...
Most likely it does not work because of:
#(negedge hrCounter)
You are using a vector but #... works with bits. So it will look at the LS bit only.
As to your code:first and most start using a clock. Do not use posedge and negedge of your signals to drive the other signals.
You use:
always#(posedge secInc ...
...
if (secInc == 1'b1)
Remove the 'if'. you have that condition already in your always statement. (But the signal should not be the 'always' anyway, it should be your clock)
Remove the 'initial' sections You have a reset which defines the start condition.
If you have an active low reset reflect that in the name. Call it reset_n or n_reset anything but 'reset' which is per convention a positive reset signal.
If your drive ANYTHING from an edge, be it from a clock or from other signals, use non-blocking assignments "<="
Do not use your generated signal edges to generate other signals. As mentioned use a clock for everything an in the clocking section use an if. Also do not drive signals from different 'always'. You can never know in which order they are executed and then you have a race condition. Thus the clear and the increment are all in one always block:
if (secCounter == 6'b111100) begin
minOut <= 1'b1;
secCounter <= 6'b0;
end
else
secCounter <= secCounter + 6'b000001;
Because of the timing aspect you now have to go to 59 not 60. Which is as you should expect as digital clocks and watches run from 00 to 59, not 00 to 60. You are allowed to use decimal numbers which will, again, make the code more readable: 6'd59, 4'd11

Verilog: Implement a Pipeline hardware using flipflops

How to create a simple one stage pipeline in Verilog?
The easiest way to create a single state pipeline is create two always block synchronized with piped input(in_pipe) as given below. This work because of how the events are queued in the simulator time cycle.
module pipeline (reset,in,clock,out)
input reset, input, clock;
output out;`
logic reset, input, clock;
reg out, in_pipe;
always #(posedge clock or negedge reset)
begin
if(reset)
begin
in_pipe <= 0;
end
else
begin
in_pipe <= in;
end
end
always #(posedge clock or negedge reset)
begin
if(reset)
begin
out<= 0;
end
else
begin
out<= in_pipe;
end
end
module pipeline#(
parameter PIPE_NUM = 2,
parameter DATA_WIDTH = 32
)(
input clock,
input [DATA_WIDTH-1:0]data_in,
output [DATA_WIDTH-1:0]data_out
);
//synthesis translate_off
initial begin
if(PIPE_NUM < 1) begin
$fatal("Error: PIPE_NUM must be greater than 0!");
end
end
//synthesis translate_on
reg [DATA_WIDTH-1:0]pipeline_reg[PIPE_NUM-1:0]/*synthesis preserve*/;
assign data_out = pipeline_reg[PIPE_NUM-1];
integer p;
always #(posedge clock)begin
pipeline_reg[0] <= data_in;
for(p = 1;p < PIPE_NUM;p = p+1)begin
pipeline_reg[p] <= pipeline_reg[p-1];
end
end
endmodule

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