Can any one explain me the reason why this particular module doesn'twork when we use '<=' instead of '='
module TestCell(x0, x1, y0, y1, z);
input x0, x1, y0, y1;
output z;
reg z;
reg a1, a2, a3, a4;
always #(x0 or x1 or y0 or y1) begin
a1 <= ~(x0 & y1);
a2 <= ~(y0 & x1);
a3 <= ~(a2 | a1);
a4 <= a2 & a1;
z <= ~(a4 | a3);
end
endmodule
And what we should ensure in order to use '<=' in verilog.
As Cthulhu has said = is blocking, That implies the statement will be evaluated before moving on to the next line of code.
always #* begin
a = b & c;
d = e & f;
g = a & d ;
end
The above example is the same as :
always #* begin
g = b & c & e & f;
end
However if we switch to using <= Then they are no longer the same in simulation, the g will be the OLD a AND OLD b. Since this is a combinatorial block, ie not regularly triggered or evaluated like a flip-flop, you will get odd results from simulation.
Correct use of the <= non-blocking assignment is in implying flip-flop.
always #(posedge clk or negedge rst_n) begin
if (!rst_n) begin
a <= 1'b0;
d <= 1'b0;
g <= 1'b0;
end
else begin
a <= b & c;
d <= e & f;
g <= a & d ;
end
end
In the Flip-Flop example above g takes the value of a and d from last clk cycle not the current evaluation.
In your example you have used always #(sensitivity list), that is a combinatorial circuit and = would be the correct usage. I would also recommend switching to always #* if your simulator allows it. The * is a wildcard and removes the need for manually entering the sensitivity list.
I think that is is worth remembering that synthesis tools will base their results on the statement following the always # If it is edge based they will use a type of flip-flop if it is combinatorial they will place combinatorial logic. The use of = or <= only has an effect in simulation. Using the wrong type means your simulation will not match the synthesised hardware.
In the case of combinational logic there is "=" for assignment, and for the sequential block we have the "<=" operator.
"=" is blocking assignment and "<=" is nonblocking assignment.
"=" executes code sequentially inside a begin / end, whereas nonblocking "<=" executes in parallel.
More
Related
I am working with a verilog module (shown below) has two always blocks. Won't there be some sort of race condition since one block sets a register and the other uses the register. What kind of issues would this cause?
Thanks,
Stephen
module XYZ
(
input wire CLK,
input wire Reset,
input wire nReset,
input wire [15:0] X,
input wire [15:0] A,
input wire T,
input wire B,
output reg M
);
assign C = X > A;
reg P;
reg N;
always #(posedge CLK, negedge nReset)
begin
if (~nReset)
begin
P <= 1;
N <= 1;
end else begin
if (Reset)
begin
P <= 1;
N <= 1;
end else begin
P <= T? 1: ((C & ~M)? 0: P);
N <= B? 1: ((M & ~C)? 0: N);
end
end
end
always #(posedge CLK, negedge nReset)
begin
if (~nReset)
begin
M <= 0;
end else begin
if (Reset)
begin
M <= 0;
end else begin
M <= M? ~(N & ~C): (P & C);
end
end
end
endmodule
No, there is no race condition. Verilog is an event-driven simulator. Posedge (unless there is a glitch in the clock or reset) is usually executed once per the simulation tick. If you use non-blocking assignments correctly (and it looks like you did), every always block triggered by an edge will use old versions of the input variable values, the values which existed before the clock edge.
Here is a simplified example:
always #(posedge clk)
r <= in;
always #(posedge clk)
out <= r;
What happens in this situation is the following:
r will be assigned the value of in later at the simulation tick, after the always blocks have been evaluated (see the nba scheduling region).
since r has not been yet really changed, the out will be scheduled to be assigned the value of r with the value before the edge.
If r was 0 before the edge and in was 1, at the end of the simulation r will become 1 and out will become 0.
This mimics behavior for real flops in hardware.
In your case it might look as a loop dependency. In reality it it none. For the same reason as above the M value will be the one from before the the posedge and will not cause any race. Flops cannot be involved in the combinational loops due to their properties logical properties.
I completely Agree with the above answer and i would suggest some more to the above answer, when i started learning Verilog i too got the same doubt and these lines from a ref. book clarified my doubts. I am coping the statement here and
for further doubts u can comment here or u can see the
Ref. book page number 135
Book name :Verilog HDL: A Guide to Digital Design and Synthesis,
Second Edition By Samir Palnitkar
nonblocking statements used in Example 2 eliminate the race condition.
At the positive edge of clock, the values of all right-hand-side
variables are "read," and the right-hand-side expressions are
evaluated and stored in temporary variables. During the write
operation, the values stored in the temporary variables are assigned
to the left-handside variables. Separating the read and write
operations ensures that the values of registers a and b are swapped
correctly, regardless of the order in which the write operations are
performed.
On the downside, nonblocking assignments can potentially cause a
degradation in the simulator performance and increase in memory usage.
//Example 2: Two concurrent always blocks with nonblocking
//statements
always #(posedge clock)
a <= b;
always #(posedge clock)
b <= a;
And u can use this type of coding style not compulsory but for the ease of debugging and to fasten simulation u can reduce the usage of begin-end blocks where ever possible
module XYZ
(
input wire CLK,
input wire Reset,
input wire nReset,
input wire [15:0] X,
input wire [15:0] A,
input wire T,
input wire B,
output reg M
);
reg P,N;
always #(posedge CLK, negedge nReset)
if (~nReset)begin
P <= #10 1;
N <= #10 1;
end else if (Reset) begin
P <= #10 1;
N <= #10 1;
end else begin
P <= #10 T ? 1 : ((C & ~M) ? 0: P);
N <= #10 B ? 1 : ((M & ~C) ? 0: N);
end
always #(posedge CLK, negedge nReset)
if (~nReset) M <= #10 0 ;
else if ( Reset) M <= #10 0 ;
else M <= #10 M ? ~(N & ~C): (P & C);
assign C = X > A;
endmodule
I'm trying to implement the following Sequential Circuit in Verilog (Modelsim 10.4a)
Here's the code I'm using
seq_circuit1.v
module seq_circuit1(x, clk, Q0, Q1);
input x, clk;
output Q0, Q1;
reg J0,K0,J1,K1;
always #(negedge clk)
begin
//Blocking and Non Blocking both will work
J0 = Q1 & ~x;
K0 = Q1 & x;
J1 = x;
K1 = (Q0 & x) || (~Q0 & ~x);
jkfflop JKff0 (J0,K0,Q0);
jkfflop JKff1 (J1,K1,Q1);
end
endmodule
jkfflop.v
module jkfflop(J,K,clk,Q);
input J,K,clk;
output Q;
if(J==0 & K==1)
begin
assign Q = 0;
end
else if(J==1 & K==0)
begin
assign Q = 1;
end
else if(J==1 & K==1)
begin
assign Q = ~Q;
end
endmodule
I'm getting some errors and I'm unable to figure out why. Can anybody tell me where did I do it wrong..
seq_circuit1
You can't instantiate submodules (your FFs) inside an always block.
Move them outside, either before or after.
Your instantiations for jkfflop are missing the clk input signal.
based on your diagram, your inputs to the FFs should be combinational logic, not sequential, and should therefore use an always #(*) block, not a clocked one.
jkfflop
if statements in verilog are only valid inside a generate, always or inital block. Since this is a FF, you'll want an always #(posedge clk) or always #(negedge clk)
If using an always block, replace the assign statements with non-blocking assignments (<=). We use NBA's here instead of a blocking assignments (=), as it's an edge-triggered block.
If assigning a value to Q inside an always block, change output Q to output reg Q
If I have a number of registers;
reg a;
reg b;
reg c;
is it possible to set a value (1'b0) to all of them in a single line (like in C), inside an always block, like this:
a <= b <= c <= 1'b0;
or would it see the two right-most non-blocking assignment operators as less-than-or-equal-to operators and do a logic evaluation?
Or would it be possible with blocking operators?
a = b = c = 1'b0;
In SystemVerilog, you can do
{a,b,c} <= '0; // non-blocking
or
a = (b = (c = '0) ); // blocking
I am working with an Altera DE2 development board and I want to read an input in on the switches. This is stored in registers. Based on a counter these registers are incremented. The registers are then supposed to be output to the Seven Segment Displays thought a B2D converter. But I can not pass a register to a function.
wire [26:0] Q,Q2,Q3,Q4;
wire [3:0] one,two,three,four;
reg SecInc,MinInc,HrInc;
reg [3:0] M1,M2,H1,H2;
assign one = SW[3:0];
assign two = SW[7:4];
assign three = SW[11:8];
assign four = SW[15:12];
always begin
M1 = SW[3:0];
M2 = SW[7:4];
H1 = SW[11:8];
H2 = SW[15:12];
end
This is how I get and store the inputs. They come from the switches which we use as a binary representation on Hours and Minutes.
Based on a counter we increment a minute or an hour register.
//increment seconds from 0 to 60
counter seconds (SecInc,KEY[0],Q2);
defparam seconds.n = 8;
defparam seconds.mod = 60;
always # (negedge CLOCK_50) begin
if (Q2 >= 60) begin
MinInc = 1;
M1 <= M1 + 1'b1;
if(M1 >= 9) begin
M1 <= 0;
M2 <= M2 + 1'b1;
end
end else begin
MinInc = 0;
end
end
We want to display the result on the SSD's.
hex(M1,HEX4);
hex(M2,HEX5);
hex(H1,HEX6);
hex(H2,HEX7);
Here in lies the problem. This is not allowed in verilog. I need a way to send my registers to a function which displays numbers from 0 to 9 using some B2D conversion.
I will say I have never had a formal intro to verilog before and I have tried all I can think to do. I even tried to make a new module in which I would pass one,two,three,four and have the module increment them, like it does with Q2 for the counter I have shown. Any suggestions or help is greatly appreciated!
As requested here is the hex module:
module hex(BIN, SSD);
input [15:0] BIN;
output reg [0:6] SSD;
always begin
case(BIN)
0:SSD=7'b0000001;
1:SSD=7'b1001111;
2:SSD=7'b0010010;
3:SSD=7'b0000110;
4:SSD=7'b1001100;
5:SSD=7'b0100100;
6:SSD=7'b0100000;
7:SSD=7'b0001111;
8:SSD=7'b0000000;
9:SSD=7'b0001100;
endcase
end
endmodule
Thank you in advance!
Your hex module is not a function, it is a module and therefore must be instantiated with an instance name like this:
hex digit0(.BIN(M1), .SSD(HEX4));
hex digit1(.BIN(M2), .SSD(HEX5));
hex digit2(.BIN(H1), .SSD(HEX6));
hex digit3(.BIN(H2), .SSD(HEX7));
In addition to nguthrie being correct, that you need to instantiate your hex converter as a module, you drive M1 from a race condition in your always block. Non-blocking assignments will evaluate simultaneously within a block (or essentially simultaneously). This is not a program, where things happen in order. What might work better is:
always # (negedge CLOCK_50) begin
if (Q2 >= 60) begin
MinInc = 1;
if (M1 < 9) begin
M1 <= M1 + 1'b1;
end else begin
M1 <= 0;
M2 <= M2 + 1'b1;
end
end else begin
MinInc = 0;
end
end
You will also potentially get unexpected results from your blocking assignments to MinInc, but since I don't see where this is read it's hard to know what will happen.
Read up on blocking (=) vs non-blocking (<=) assignments in Verilog. It's one of the trickiest concepts of the language, and misuse of the two operations is the cause of 90% of the most dastardly bugs I've ever seen.
EDIT: In re-reading your question, it seems that you're trying to drive M1-4 from at least three places. You really can't have a continuous always begin block and a clocked (always # (negedge clock) begin) driving the same register. This will send your compiler into a tantrum.
I am new to verilog and I am working on verilg code that defines two modules.
The first module calculates the mod of 2 numbers and the second uses the result to do some operation on it.
The result was wrong and has alot of don't care values because the same clk was used in both modules. Any suggestion please for synchronisation.
The mod module
module mod(m,a,b);
input [15:0] a,b;
output [15:0] m;
reg [31:0] mod;
reg [31:0] mul;
integer i;
always #* begin
mul = a*b;
mod = 32'h80008000;
for(i=0;i<16;i=i+1) begin
if(mul > mod) begin
mul = mul - mod;
mod = mod >> 1;
end
else begin
mod = mod >> 1;
end
end
assign m=mul[15:0];
endmodule
Part of the top module:
initial begin
keyp <= 2'b10;
shift <= 1'b0;
end
always #(posedge clk) begin
if(load)
case (keyp)
2'b10: begin
key[127:64] <= {k1,k0};
keyp <= 2'b01;
end
2'b01: begin
key[63:0] <= {k1,k0};
keyp <= 2'b00;
shift <= 1'b1;
end
//default: keyp <=2'b00;
endcase
else if (shift) begin
//shift key for first round
temp[24:0] <= key[127:103];
key[127:25] <= key[102:0];
key [24:0] <= temp [24:0];
shift <= 1'b0;
end
end
assign w1[2*SIZE-1:SIZE] = d1+key[2*SIZE-1:SIZE];
assign w1[3*SIZE-1:2*SIZE] = d2+key[3*SIZE-1:2*SIZE];
mod mod1( w1[SIZE-1:0], d0, key[SIZE-1:0] );
mod mod2( w1[4*SIZE-1:3*SIZE], d3, key[4*SIZE-1:3*SIZE]);
Assigning to the same value multiple times with blocking assignments is perfectly valid Verilog. Even having the same term appear on both sides is fine, provided it's been assigned at least once prior to that.
The code here is incomplete but the problem appears to be that the code is assigning to 'key' in multiple places. Both as the output of the mod instances and inside the clocked block. Anytime these two 'disagree' about the value of key it's going to been seen as an X. X in addition to representing unknown also reflects contention where two different assignments conflict.
Since I'm not sure what this code is meant to do (seems to be some sort of encryption) I can't offer a fix but you need to separate the assignments to key.
x's are referred to as do not cares in casex statements or Karnaugh maps, here they represent unknown values. Unknown values can come from a value not being initialised (reset) or multiple (conflicting) drivers.
The mod module contains this section of code:
always #* begin
mul = a*b;
mod = 32'h80008000;
for(i=0;i<16;i=i+1) begin
if(mul > mod) begin
mul = mul - mod;
mod = mod >> 1;
end
else begin
mod = mod >> 1;
end
end
always #* is a combinatorial block, you assign mul multiple times only the last assignment will have any effect.
The use of a for loop here makes it look like you are trying to reuse variables, as you would in c. Remember that we are describing hardware and that the value is intended to exist somewhere as flip flops or wires between modules and can only hold a single value in any given clock cycle.
In the combinatorial block you have mul = mul - mod; that is mul defining itself this will not work, you need to add a flip flop to break the loop.