I know that I should be using a non-blocking assignments in sequential always assignments. However, I accidentally happen to use a blocking assignment in part of my code, here it is:
reg tb_strobe = 0;
reg [9:0] tb_strobe_cnt = 0;
reg tb_sync = 0;
always#(posedge tb_clkh)
begin
if (~tb_resetl) begin
tb_strobe <= 0;
tb_strobe_cnt <= 0;
tb_sync <= 0;
end
else begin
if (tb_strobe_cnt == 1022) begin
tb_strobe <= 1;
tb_strobe_cnt <= tb_strobe_cnt + 1;
end else if (tb_strobe_cnt == 1023) begin
tb_strobe <= 0;
tb_strobe_cnt <= 0;
end else begin
tb_strobe <= 0;
tb_strobe_cnt <= tb_strobe_cnt + 1;
end
if (tb_strobe == 1) begin
tb_sync = 1; // <-- this is the mistakenly used blocking assignment
end else begin
end
end
end
And then my simulator behaves unpredictably, and once I fixed that assignment to be a non-blocking one, it started working fine !!!!
I am curious as to what was wrong with the above (in my specific code)?
In the way that I used it, since I am only calling tb_sync once in my code, I wasn't expecting any unpredictable behavior...
And tb_sync is not being assigned anywhere else in the code. Any idea what is wrong?
Non-blocking assignments are used to prevent race conditions between multiple processes that write and read the same variable on the same clock edge. It just takes one process that writes, and another process that reads the same variable on the same clock edge to create that race. Your example does not show the process that reads tb_sync, but I'm assuming that's where the race is.
Related
I'm making a simple project with leds blinking every second. Led 1 and 3 blink alternating to led 2 and 4. I've written the following Verilog code:
module leds_blinking(input i_Clk,
output o_LED_1,
output o_LED_2,
output o_LED_3,
output o_LED_4);
parameter c_CYCLESINSECOND = 50_000_000;
reg r_LED_1 = 1;
reg r_LED_2 = 0;
reg r_LED_3 = 1;
reg r_LED_4 = 0;
reg [32:0] r_Count = 0;
always #(posedge i_Clk)
begin
if (r_Count < c_CYCLESINSECOND)
r_Count <= r_Count + 1;
else if (r_Count == c_CYCLESINSECOND)
begin
r_LED_1 <= ~r_LED_1;
r_LED_2 <= ~r_LED_2;
r_LED_3 <= ~r_LED_3;
r_LED_4 <= ~r_LED_4;
r_Count <= 0;
end
else
r_Count <= 0;
end
assign o_LED_1 = r_LED_1;
assign o_LED_2 = r_LED_2;
assign o_LED_3 = r_LED_3;
assign o_LED_4 = r_LED_4;
endmodule
All LEDs are active at the same time, though I instantiated 1,3 other than 2,4.
I’m assuming you are synthesizing and not running simulation on the RTL first. Synthesizer that target for ASIC typically ignore default values and initial blocks. Synthesizer that target for FPGA often do. Not knowing which synthesizer you are using it is hard to guess your root causes issue.
However, you can simplify your code and solve your problem by using one registers instead of four. Notice how the o_LED_# are driven.
always #(posedge i_Clk)
begin
if (r_Count < c_CYCLESINSECOND)
r_Count <= r_Count + 1;
else
begin
r_LED <= ~r_LED;
r_Count <= 0;
end
end
assign o_LED_1 = r_LED;
assign o_LED_2 = ~r_LED;
assign o_LED_3 = r_LED;
assign o_LED_4 = ~r_LED;
Im currently working on the Shift-Add Algorithm (32x32 bit Multiplication) in System Verilog. System Verilog cant find any error and my code is working correctly according to GTKwave. When I synthesize my circuit with yosys, Latches will be added. And that is the Problem. I dont want Latches in my Circuit. Heres my Code:
module multiplier(
input logic clk_i,
input logic rst_i,
input logic start_i,
input logic [31:0] a_i,
input logic [31:0] b_i,
output logic finished_o,
output logic [63:0] result_o
);
typedef enum logic [1:0] { STATE_A, STATE_B} state_t;
state_t state_p, state_n;
logic [63:0] fin_res;
logic [63:0] tmp;
logic rst_flag;
integer i;
always #(posedge clk_i or posedge rst_i) begin
if (rst_i == 1'b1) begin
state_p <= STATE_B;
end
else begin
state_p <= state_n;
end
end
always #(*)begin
state_n = state_p;
case (state_p)
STATE_A: if (start_i == 0) state_n = STATE_B;
STATE_B: if (start_i == 1) state_n = STATE_A;
default: state_n = state_p;
endcase
end
always #(*) begin
case (state_p)
STATE_A: begin
rst_flag = 1;
fin_res = 0;
finished_o = 0;
tmp = 0;
for (i = 0; i < 32; i = i + 1) begin
if (a_i[i] == 1'b1) begin
tmp = b_i;
tmp = tmp << i;
fin_res = fin_res + tmp;
end
end
end
STATE_B: begin
result_o = fin_res;
if (rst_flag == 1) finished_o = 1;
if (start_i == 1) finished_o = 0;
end
default: begin
finished_o = 0;
result_o = 0;
end
endcase
end
endmodule
After spending 2 days only with debugging and not finding any mistake I would like to ask if u could help me. I am assigning every output (at least I think so). So where is my mistake? Is it the for loop? But what would be wrong with it? Thanks in advance for your help :)
Some useful Information for the Code-Snippet: start_i is the starting signal. If this is set to 1 the multiplication should be started. finished_o is the finish flag. If this is set to 1 the CPU will know that the computation is completed. a_i and b_i are the inputs which should be multiplied. result_o is the result of the multiplication which can be read when finished_o is set to 1.
According to yosys i get the following latches:
64 DLATCH_N
64 DLATCH_P
I think something may be wrong with fin_res in the for loop cause that logic variable is exactly 64 bits long as are the Latches
From the comment you have a bunch of variables which are not assigned in the second case statement causing synthesis to generate latches. To avoid it you need to assign all the vars in all branches of the case statement and conditional statements recursively.
However, if there is a default value you can assign to all of them, you can use a pattern similar to the one from the second always block, just assigning default values before the 'case' statement. This way you do not even need the default clause and you can get rid of it in the second always block as well.
always #(*) begin
// set default values
rst_flag = 0;
fin_res = 0;
finished_o = 0;
tmp = 0;
result_o = 0;
case (state_p)
STATE_A: begin
rst_flag = 1;
for (i = 0; i < 32; i = i + 1) begin
if (a_i[i] == 1'b1) begin
tmp = b_i;
tmp = tmp << i;
fin_res = fin_res + tmp;
end
end
end
STATE_B: begin
result_o = fin_res;
// are you sure that you do not need a latch here?
if (rst_flag == 1) finished_o = 1;
if (start_i == 1) finished_o = 0;
end
// you do not need 'default' here.
endcase
end
My fixes will cause combinational behavior and should get rid of latches in synthesis, but it does not look like they will behave as you expected. It looks like you really need a latches here.
rst_flag must be a latch. You set it in STATE_A and use it in STATE_B. It has to keep the value between states. This is a latch behavior.
In STATE_B you change finished_o only if some of conditions met. What happens if the rst_flag and start_i are both 0. do you want finished_o to be 0 or the previous value? In the latter case you need a latch.
How about fin_res ? What do you want to do with it in other states? keep previous value (latch) or have a default value (no latch).
...
I am receiving this error from Quartus when trying to compile:
Error (10200): Verilog HDL Conditional Statement error at
time_of_day_FSM.v(166): cannot match operand(s) in the condition to
the corresponding edges in the enclosing event control of the always
construct
Here is some background. I am making a clock, and for this always block, I want to increment and set certain values to resemble the behavior of a clock in the format of hh:mm:ss. I have a clock source that goes high every millisecond, and am using a counter to set the secondPassed reg.
I want the code in the block to update every time a second passes, like a clock, or KEY[2] is pressed on my board (down = 0), as this is what the user uses to increment the hours, minutes, or seconds when setting the clock time. Here is the always block in question (sorry for the nested if statements, I can't think of a better way to do it):
// every second. Used just to keep time going. Independent of states.
always #(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else if(secondPassed == 1 || KEY[2] == 0) begin // I don't care about explicitly stating the conditions, as the sensitivity list covers that right?
if(sec0 == 9) begin
sec0 <= 0;
if(sec1 == 5) begin
sec1 <= 0;
if(min0 == 9) begin
min0 <= 0;
if(min1 == 5) begin
min1 <= 0;
if(hr1 == 1) begin
if(hr0 == 2) begin
hr0 <= 1; // go to 1 o'clock
hr1 <= 0;
end
else hr0 <= hr0 + 1;
end
else hr0 <= hr0 + 1;
end
else min1 <= min1 + 1;
end
else min0 <= min0 + 1;
end
else sec1 <= sec1 + 1;
end
else begin
sec0 <= sec0 + 1;
end
just_flashed <= ~just_flashed;
end // end big else
end // end always
My question is: Why does the Quartus compiler complain if I try to make the non-reset scenario JUST AND ELSE, like this:
// every second. Used just to keep time going. Independent of states.
always #(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else begin // this is causing the issue. compiler complains .
// same logic to drive clock as above
just_flashed <= ~just_flashed;
end // end big else
end // end always
I feel I have seen many examples where people simply use and else begin end for their code. My code seems to want my to EXPLICITLY restate the conditions of the sensitivity list for the else if. Any explanation? I am new to large verilog projects.
You are mixing combinational logic and synchronous logic in the always block and this is bad habit of coding. Generally, there are 2 main always blocks in most designs.
A combinational:
always#(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always#(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always blocks' sensitivity list properly the problems has to be solved.
the picture indicates what I want the output signal is: the high signal double and the low signal keep same.
I wrote the code like:
integer x=0, count_valid=1, count_down=0;
reg valid_1, valid_reg;
always#(posedge clk)
begin
if(tag==1) begin
if(valid) begin
count_valid <= count_valid +1;
x<=x+1;
valid_reg <= 1;
end
else begin
x<=0;
count_down <= count_down+1;
if(count_valid>0) begin
valid_reg <= 1;
count_valid <= count_valid -1;
end
else if(count_down>0) begin
valid_reg <= 0;
count_down <= count_down-1;
end
end
end
else begin
valid_reg <= valid;
if (valid) x<=x+1;
else x<=0;
end
valid_1 <= valid_reg;
end
valid is the original signal in the picture and valid_reg is the modified signal. the count_valid is used to count how many cycles for high and use it to sub one to achieve the doubling. then count_down is for counting the cycles of low signal. but I realized when valid high the valid_reg will high.
can anyone give me some idea how to make the low signal run same cycles in output signal? any idea is also great.
You didn't mention if the input signal was periodic or not. Given the fact that your output is stretched over time, if the input is not periodic, then you would need infinite storage to keep track of what the input signal looked like. If it is periodic, or quasi-periodic, you can do something like below.
Keep track of the high count and low count in one block, and generate the output signal in another block, using the current registered values of the counts. Getting the output's first edge to line up with the input's is kind of tricky, requiring a mux, selected depending on whether it's the first time through the loop or not.
integer count, count_q, countdown, countdown_q, outcount;
logic valid_q, valid_reg, out_q;
logic new;
always #(posedge clk or negedge reset_n)
begin
if(~reset_n)
begin
if(~reset_n)
begin
new <= 1;
valid_q <= 0;
count_q <= 0;
countdown_q <= 0;
end
else
begin
valid_q <= valid;
if(valid & ~valid_q)//rising edge
begin
count <= 1;
countdown_q <= countdown;
end
else if(~valid & valid_q)//falling edge
begin
new <= 0;
count_q <= count;
countdown <= 1;
end
else if(valid)
count <= count+1;
else
countdown <= countdown+1;
end
end
end
always #(posedge clk or negedge reset_n)
begin
if(~reset)
begin
outcount <= 0;
out_q <= 0;
end
else
begin
if(new & valid & ~valid_q)
begin
out_q <= 1;
outcount <= 2;//valid_reg is already high here
end
else
if(out_q && (outcount == (count_q<<1)))
begin
out_q <= 0;
outcount <= 1;
end
else if(~out_q && (outcount == (countdown_q)))
begin
out_q <= 1;
outcount <= 1;
end
else
outcount <= outcount + 1;
end
end
assign valid_reg = new? valid : out_q;//this gets your initial rising edge lined up
I'm implementing a simple serializer in Verilog, but I do not understand the nuances of when blocking assigns can cause problems. I'm specifically having trouble understanding part of this answer. "However, you should never use blocking assignments for synchronous communication, as this is nondeterministic."
I'm building a block that takes, as an input:
A bit clock
A 5-bit parallel data input (the value to be serialized)
A "Data valid" signal that indicates valid 5-bit data is present
As an output, I have:
Serial data out
A "Complete" signal that indicates it's time for a new 5-bit value
A "Transmitting" signal that's high whenever there's valid serial data going out on the bus
Whenever data valid goes high, the block starts outputting the 5-bit value, one bit a time, starting at the next rising edge of the bit clock. When the last bit is out on the wire, the block signals "complete" so a new 5-bit value can be made available.
Omitting some of the reset logic, the code to do this looks like this:
always # (posedge clk) begin
if(shiftIndex == 0) begin
if(dataValid == 1) transmitting = 1; //Blocking assign
else transmitting = 0; //Blocking assign
end
//Need the blocking assign up above to get this part to run
//for the 1st bit
if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
Now, I can write the block with all non-blocking assigns, but I feel that it hurts readability. That would look something like this:
always # (posedge clk) begin
if(shiftIndex == 0) begin
if(dataValid == 1) begin
transmitting <= 1; //Non-blocking now
shiftIndex <= shiftIndex + 1; //Duplicated code
dataOut <= data5b[shiftIndex]; //Duplicated code
complete <= 0; //Duplicated code
end
else transmitting <= 0;
end
//Now, this only runs for the 2nd, 3rd, 4th, and 5th bit.
else if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
Both appear to do what I want in simulation, and I favor the 1st one because it's easier for me to read but since I don't understand why using blocking assignments for synchronous communication is nondeterministic, I'm worried that I've coded up a ticking time bomb
The Question: Am I doing something wrong in the 1st code that's going to blow up when I try to synthesize this? Is the 2nd code preferable despite being a bit harder (for me anyway) to read? Is there some 3rd thing I should be doing?
When using the blocking (=) assignment the value is available to use in the next line of code. This implies it is combinatorial and not driven from a flip-flop.
In simulation it looks like it is driven from a flip-flop because the block is only evaluated on positive clock edge, in reality it is not which might break the interface.
I am of the faction which says never mix styles, as it can be a problem in code reviews and refactoring. The refactor, if a module needs to output a new signal and it is seen that it already exists they just change to be an output. At first glance looked like it was a flip-flop because it was in a always #(posedge clk block.
Therefore I would recommend to NOT mix styles, but pull out the section that is combinatorial and put it in its own block. Does this still meet your requirements? if not then you would have had problem.
I do not see how data valid is controlled but it can change the output transmitting, potentially transmitting could also glitch as it is from a combinatorial decode, not driven cleanly from a flip-flop. The receiving interface might be async, glitches could cause lock up etc.
always #* begin
if(shiftIndex == 0) begin
if(dataValid == 1) transmitting = 1; //Blocking assign
else transmitting = 0; //Blocking assign
end
end
always # (posedge clk) begin
if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
As far as correctness is concerned, there is no problem with mixing blocking and non-blocking assignments, but you need to have a clear understanding of which signal is sequential and which signal is combinational block (note that the inputs of this combinational block come either from other sequential blocks or primary inputs). Also, you need to decide if you want any latches in your design or not.
If you use blocking assignments for a variable that you don't mean to be sequential, make sure to always assign to it, otherwise, it might be interpreted as a sequential element.
In your first code, you don't assign to transmitting when (shiftIndex != 0). This implies the previous value of transmitting should be used when (shiftIndex != 0), hence it would be a sequential element. But you need its value in the current clock, hence you used a blocking assignment.
Below is another version of your code, where firstBit_comb for the first bit is used and is always assigned to.
always # (posedge clk) begin
//Default value to avoid sequentials. Will be overwritten later if necessary
firstBit_comb = 0;
if(shiftIndex == 0) begin
if(dataValid == 1) begin
transmitting_seq <= 1;
firstBit_comb = 1;
end
else begin
transmitting_seq <= 0;
firstBit_comb = 1;
end
end
//Need the blocking assign up above to get this part to run
//for the 1st bit
if(firstBit_comb || transmitting_seq) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
It is however more clear if you separate sequential and combinational blocks. Note that the next state of your sequential elements is often an output of a combinational block.
//combinational block
always_comb
begin
//The default value of next state is the previous state
transmitting_next = transmitting_seq;
//The default value of firstBit_comb=0. It would be overwritten if necessary
firstBit_comb = 0;
if(shiftIndex == 0 && dataValid == 1) begin
firstBit_comb = 1;
transmitting_next = 1;
end
else begin
firstBit_comb = 0;
transmitting_next = 0;
end
end
//Sequential block
always # (posedge clk) begin
//update transmitting_seq with its next state
transmitting_seq <= transmitting_next;
if(firstBit_comb || transmitting_seq) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end