Picture given is a module I'd like to express.
MulCell
For some reason I had to bring up the Multiplicand or Multiplier from arrays of numbers using wire. ex)wire [3:0] abc = 4'b1111;
But very odd! When I assign specific value of wire abc to "Multiplier", it works well. However if I assign it to "Multiplicand", I see red lines just as in the picture. redline
Any idea what had gone wrong? Thanks
Code for MulCell
module MulCell(Multiplicand,Multiplier,Sin,Cin,Sout,Cout);
input Multiplicand,Multiplier,Sin,Cin;
output Sout,Cout;
reg Sout,Cout;
wire tmp;
assign tmp=Multiplicand&Multiplier;
always#(tmp) begin
{Cout,Sout} <= tmp+Sin+Cin;
end
endmodule
Code for testbench_MulCell
`timescale 1ns/1ns
module testbench_MulCell();
reg Multiplicand,Multiplier,Sin,Cin;
wire Sout,Cout;
MulCell MC(Multiplicand,Multiplier,Sin,Cin,Sout,Cout);
wire [3:0]abc;
assign abc=4'b1111;
initial begin
Multiplicand=abc[2];
Multiplier=1'b1;
Sin=1'b1;
Cin=1'b1;
#10 //expecting 11
Multiplicand=1'b0;
Multiplier=abc[1];
Sin=1'b1;
Cin=1'b1;
#10 $stop;//expecting 10
end
endmodule
I can be wrong, but it seems there's a race condition between assigning value to abc and running initial block. At the moment when initial block started running, the assign abc =.. isn't executed yet. That's why you get x/red_lines in waveform view.
Verilog is an event driven simulator. It means that every 'always...', 'assign' block has inputs and outputs. Inputs in always block is are represented by its sensitivity list. In your case that would be the tmp signal. The whole block will start evaluation if and only if a change of an input is detected.
Also in the module the initial is scheduled for execution once during the simulation and is always executed first, before any of the always blocks (except in special cases in system verilog). So, in your case first few statements of the initial block (before first #10) are executed before the assign statement. So, for the first 10 cycles value of abc will be `4bxxxx, which explains your red line. For the same reason the values. As a result, values of multiplicand and consequently of MC/tmp,Sout,Cout will also be 'x'.
At #10 you change the values of the variables, causing always block in MC to re-evaluate with new values. By that time abc is already set to 1111 and all 'x' disappear.
So, efficiently you simulated only the second set of values but hot the first.
The suggestion is: add a small delay in front of the initial block:
initial begin
#1
Multiplicand=abc[2];
Multiplier=1'b1;
Sin=1'b1;
This will delay execution of the statements and the value of 'abc' will be set by this time. You will have a short period (1) of the red line, but you will see results of the values you set.
Another possibility is to set value of abc in the initial block first, but you would need a reg variable to do so:
reg[3:0] abcSet;
assign abc = abcSet;
initial begin
abcSet = 4'b1111;
...
another thing, in your always block you use non-blocking assignment (<=). Do not! This is good for flops and latches but bad for simple combinatorial logic. Use the regular assignment there (=).
{Cout,Sout} = tmp+Sin+Cin;
Also, this always block will not be avaluated if you just change Sin or Cin and tmp stays the same. You should either add those into the sensitivity list:
always #(tmp, Sin, Cin)
or use always #* instead. Actually it is a good idea to always use this construct instead of regular V95 always blocks. This way you will avoid possible implicit latches in the design (as in your case in respect to missing parts of the sensitivity list).
Also, in general most of the modern designs are synchronous designs and use a clock signal for synchronization. In your case the multpliplier sell shoudl be synchronized as well, you would need to provide a toggling clock signal. In theis case your operation could look like the following:
always #(posedge clk)
{Cout,Sout} <= tmp+Sin+Cin;
It makes evaluation happen at positive edge of the clk signal, it it is the only member of the sensitivity list. All other signals should set before the clock change. And yes, it is a flop and <= is used there.
Related
The following code gives output ("fact") 1 irrespective of the input. What is the error?
module Factorial_calc(n, fact);
input [5:0] n;
output reg [64:0] fact;
reg [5:0] i;
initial
begin
i=n;
fact=1;
end
always #(*)
begin
while(i>0)
begin
fact=i*fact;
i=i-1;
end
end
Verilog will not stop you from assign a reg to a net's value within an initial block, but you are extremely unlikely to get the result you expect.
An initial block runs ones at time 0. The net may not have the intended value before it is assigned to the reg. By design, Verilog allows for non-determinism of the evaluation order of procedural blocks and contentious assignments within the same phase of a time-step. Verilog's evaluation order can be controlled by event dependency. initial blocks do not not event dependencies, so it will always be evaluated as soon as possible. Nets will have dependencies (unless they are assigned to constants) so the typically are evaluated later.
The minimum change to get your code to work is to move the content of the initial block to inside the always block above the while statement. This will update i every time input n changes and reset fact before it is updated in the while loop.
always #(*)
begin
i = n; // <-- local sample
fact = 1; // local reset
while(i>0)
begin
fact=i*fact;
i=i-1;
end
end
This will work for simulation, but it cannot synthesize because it used a while statement.
I came to know that we can use assign statements in procedural blocks(like in always), what will be the difference in using "assign" inside always block and outside it(in concern with synthesized circuit). I mean when it is absolutely necessary to use assign in always?
Never, assign keyword is for continuous assignment and it will generate combinatorial logic at synthesis. In fact, you can obtain the assign behaviour with an always block:
wire test;
//At all times, test equals input
assign test = input;
Is equivalent to:
reg test;
//Each time input changes(with the always#*), test takes its value
always#*
test = input;
In always blocks, you should only use non-blocking assignment('<=') which are procedural assignments. Using blocking assignment is possible, however, you have to be sure to do what you want.
From this thread:
Two rules to live by that I know of no exceptions:
Always use blocking assignments for combinatorial or level-sensitive code, as well a clock assignments
Always use non-blocking assignments for variables that are written on a clock edge, and read on the same clock edge in another process.
assign and corresponding deassign (in always blocks) are also called 'procedural continuous assighment' can be used in always blocks for specific purposes. In most cases this is non-synthesizable and I had never ran across its use.
an example:
reg in1, in2, out;
reg [1:0] select;
always #* begin
case (select)
2'b01: assign out = in1;
2'b10: assign out = in2;
2'b11: deassign out;
endcase // case (select)
end
general recommendateion -- do not use it.
I'm trying to design this state machine in verilog:
I was have:
`timescale 1ns/1ns
module labEightMachine(y, x,clk,clr)
output y;
input [1:2] x;
input clk, clr;
reg [1:2] q;
reg y;
reg nX;
always # (posedge clk)
begin
if(clr)
{q}<=2'b00;
else
q<= {nX}
end
always #(y,x)
begin
if(q==2'b00)
if(x==2'b00)
q<=2'b00;
else
q<=2'b01;
y<=1;
if(q==2'b01)
if((x==2'b00)||(x==2'b01))
q<=2'b00;
y<=0;
else
q<=2'b11;
y<=0;
if(q==2'b11)
if(x==2'b10)
q<=2'b10;
y<=1;
else
q<=2'b00;
y<=0;
if(q==2'b10)
q<=2'b00;
y<=0;
end
endmodule
If any one could help by telling me where it is incorrect, that would be greatly appreciated. The state machines confuse me and I'm not sure that I am reassigning everything correctly.
Applying stimulus is always a better way to check your code. Leaving the syntax errors of semi-colons/begin-end and all that, a couple of immediate logical errors I can see are as below.
The declaration reg nX declares a variable of single bit width. On the contrary, q is declared as reg [1:2] q, of two bits width.
Secondly,q is driven from two always blocks. If clr is LOW, then q is driven by nX. While, nX is never driven by any signal. So, the output will be x majority of times (leaving those race-conditions). Multiple driver issues.
Thirdly, it would be better to use if--else if--else ladder instead of multiple ifs. This will make the next_state logic clear.
A better FSM, might have two always blocks and one output logic block. One for sequential logic and other for combinational logic. Sequential block is used to update the current_state value by the next_state value. While, a combinational block is used to update the next state value according to inputs. The output logic must either have a separate block of continuous assignments or a procedural block.
Also, it might be convenient to use a case statement for next_state logic. This will be useful when too many states are interacting with each other in a single FSM. Using default in case statement is inevitable.
For further information on efficient FSM coding styles, refer to CummingsSNUG1998SJ_FSM paper and CummingsSNUG2000Boston_FSM paper.
I'm running into some problems implementing a synthesizeable state machine to output the results from several lower-level modules I've already implemented. As far as I can tell, the structure I have so far wants nested always blocks, but that can't be done in Verilog. I'm not sure how to circumvent this problem.
EDIT: code taken down as at least one classmate has turned in identical (and non-functioning, lol) portions of my own code.
If you think you need nested always blocks then you are likely not thinking about hardware design, while RTL gives some abstraction from the electronic components it has to be written in such away that represent possible hardware behaviour.
always #* represents a combinatorial block.
always #(posdege clk) represents sequential logic, where the outputs are driven by flip-flops.
always blocks tell the simulator when to trigger the block for simulation, as everything is happening at once, it is all parallel. The simulator could not know when to schedule code not contained in these blocks.
You need to have always #(posedge KEY[0] and always #(posedge KEY[1] which each contain the case statement. If they are not to do anything for a particular case then hold or Zero the current values. You can have a default: case as a catch all for those unspecified.
Update
Regarding the rotate function you should be able to take the MSB to indicate if negative.
Use >>> to preserve sign bits. you might need to declare the reg/wires assigned or add $signed function
reg signed [msb:0] data_in;
always #(posedge clk) begin
if (data_in[msb] == 1'b0) begin
data_out <= data_in <<< 1;
end
else begin
data_out <= data_in >>> 1;
end
end
// or use $signed(data_in) >>> 1;
You appear to have everything inside an initial block, so looking for a posedge doesn't even make sense. In general, initial blocks are not synthesizable.
No, you can't nest always blocks and you shouldn't need to.
You should have a single always #(posedge KEY[1]) that contains all of the possible assignments to STATE. You can't make assignments to the same reg in different always blocks. Be sure to use non-blocking assignments.
Create additional always blocks for your other reg signals, ideally using one always block per signal.
I was wondering whether it was possible for an always block to be executed only when multiple signals in the sensitivity list change together.
As in, suppose I have a signal 'in' and another 'posedge clk'. I want the always block to be executed when BOTH the signals change. Is it possible, and if yes, what is the syntax for it?
In general, no there is no way to do it, as this doesn't actually map to any kind of standard logic cells that one would typically synthesize. However if you describe what your ultimate goal is, I'm sure someone can point you in the right direction while still using synthesizable logic. I'm having a hard time imagining what you could want such a block for.
This an answer to the original question, not the problem revealed in the comments
As #Tim has mentioned there is no hardware construct which can do this. always #(posedge clk) create flip-flops which sample the data on the edge of a clk.
always #* blocks create combinatorial logic which is evaluated by the simulator when ever the right hand side of an assignment or a select signal changes.
If you had multiple 1 bit signals driven from D-type flip-flops you could XOR (^) the input (D) and output (Q) to create a, 1 clock cycle wide, signal indicating the value has changed. These change signals could be combined to create an enable signal. Which is used as a select or enable for a flip-flop.
always #(posedge clk or negedge rst_n) begin
if (~rst_n) begin
//reset condition
end
else if (enabled)
//Enabled condition
end
// no final else, everything will holds its value
end
Or may be as the enable for a latch :
//synopsys async_set_reset "rst_n"
always #* begin
if (~rst_n) begin
// Reset
end
else if (latch_open) begin
//next datavalue
end
end