I am having a strange problem with Verilog HDL.
I found in my code that if I multiply a variable by two, but then
assign that value to the same variable, it gets all messed up.
Sometimes, the simv program even crashes. I originally needed to do this,
because I had a for loop for shifting or rotating a certain amount. But,
then I found that not only shifting the same variable did not work, but
also, addition, subtraction, multiplication, or division does not work either.
So in my code example, if you set a to 16'b0001_0000_1010_0101, and b to 3,
then you get an output of 16'b0000_0000_0000_0000. Just note that I am ignoring b for now... I should get 16'b0010_0001_0100_1010... but something is going wrong.
So, this is my code file test.v:
// ALU module.
module test(in1, in2, out1);
input [15:0] in1;
input [15:0] in2;
output reg [15:0] out1;
// Variables for shifting right and for rotating left or right.
reg [15:0] shiftedValue;
always#(in1, in2)
begin
assign shiftedValue = in1;
assign shiftedValue = shiftedValue * 2;
assign out1 = shiftedValue;
// This display value is correct!
// but it's still wrong in the test bench.
$display("out1 == %b", out1);
end
endmodule
module testStim;
reg [15:0] a;
reg [15:0] b;
wire [15:0] c;
// create ALU instance.
test myTest(a, b, c);
initial
begin
a = 16'b0001_0000_1010_0101;
b = 3;
#10
$display("op1In == %b, op1Out == %b", a, c);
$finish;
end
endmodule
This is the output after running simv (I stripped out the erroneous garbage...):
out1 == 0010000101001010
op1In == 0001000010100101, op1Out == 0000000000000000
Thanks,
Erik W.
You have done what is called as procedural continuous assignment.
The difference between regular continuous assignments and procedural continuous assignments is this:
Continuous assignment can only drive wire/net data type. Procedural assignment can drive only reg data type and not nets.
Continuous assignment should appear outside procedural blocks(always, initial etc), while latter must be inside procedural blocks.
Continuous assignment executes each time the right hand side expression changes. Procedural assignment depends on sensitivity list of always block.
As soon as the always block ends, the effect of assign statement is removed. You must add deassign statement to retain the values (which I think is not the real intent) or Just remove assign statement from the code. As shown below:
shiftedValue = in1;
shiftedValue = shiftedValue * 2;
out1 = shiftedValue;
More information about assign, deassign is available at this, this and this links.
Related
When exactly are the variables inside an always-block in Verilog updated?
E.g. if the reg C is changed multiple times in an always-block: does the value of it always change? Or is the value only "physically written" to the reg at the end of the always-block?
Would it be better to use an extra intermediate register which is only actualized at the end of the always-block? Would it make any difference?
reg C;
always #(*)
C = 0;
C = A;
C = 1;
C = B;
end
Other example:
If I have a module with an always block as follows, could the multiple assignments of the output exhibit sort of a glitch, where the output quickly goes to 0 before getting the value of B? Does it make a difference if I use blocking (=) or non-blocking (<=) assignments?
module example1 (output C, input A, input B);
always #(*)
begin
C = 1’b0;
if (A==1)
C = B ;
end
endmodule
Example with intermediate register to avoid unwanted change of the output.
module example1 (output C, input A, input B);
reg intermediateReg;
always #(*)
begin
intermediateReg = 1’b0;
if (A==1)
intermediateReg = B ;
end
C <= intermediateReg;
endmodule
In the examples you provided the code behaves identically to the 'c' code. The variable gets re-assigned new values and the last one wins. In verilog this is true for blocking (=) or non-blocking (<=) assignments, but not for the mix of them.
As in 'c' it is up to the compiler optimization technique. It can eliminate unneeded assignments, so only the last one is relevant.
In your first example the value of 'C' will be 'B' at the end of the block. The value of 'C' in the second example will either be 0 or B, depending on A.
Now, for the purpose of a simplicity of explanation, mixing of blocking and non-blocking assignments will cause the last 'non-blocking' assignment win. The reason is that all nba's are executed after the block is finished.
always #(*) begin
C <= A;
C = B;
end
The value of C will be A at the end of the simulation cycle.
As for the question about using intermediate values, there is no difference. You use them as needed. The simulation compiler or synthesis will optimize your code in any case. The last example is absolutely normal, except that it does not change anything at all. It behaves the same way as this, which is more explicit and more readable in my opinion. The only problem is that you incorrectly use nba assignments int combinational logic (which i fixed).
always #(*)
begin
if (A==1)
C = B ;
else
C = 1'b0;
I guess there is another silent question in your post, will the intermediate value cause events on 'C', the answer in this case is no. There will be no events produced by the always block till it finishes its execution (or till it hits a delay or starts waiting on an event). So, only the last value is relevant.
In a testbench code you can see a situation like that:
always #* begin
C = A;
C = B;
#5 C = D;
end
In the above case The value of C will become B. The execution of the always block will stop for #5 delays. During that time other blocks will see the value B. In #5 ticks, the value will be changed to D.
If you want to know what blocking and non-blocking assignments do in standard Verilog (like you would have in simulation), you can easily look that up.
If you're talking about hardware, the type of hardware you get will depend on what's in the sensitivity list, not type type of assignments you use. The type of assignment will affect the combinational logic that is synthesized from your code. Assuming you aren't doing anything unsynthesizable, the logic you get should be equivalent to what the Verilog standard specifies but won't be a 1:1 direct mapping of your code.
So, no, adding intermediates won't necessarily help with glitches in the hardware. There will be other code and timing specifications, etc. for dealing with stuff like that.
I'm trying to construct a structural implementation of a circuit that consists of a d flipflop, it has inputs x and y, x and y are exclusive or'd and that result is exclusive or'd with the current state, and used as the input to the d flip flop. and it'll use the result state from the flipflop in the next run, etc. But I'm not too sure how to construct it.
The circuit looks like so:
module dff(D,clk,q);
input D,clk;
output q;
reg q;
always # (posedge clk)
begin
q<=D;
end
endmodule
I'm pretty sure the d flip flop code is correct but when I try to test this my d and state values are just x for some reason. When I put in different x and y values in my testbench nothing happens, "state" and "d" just always says it has value "1'hx" in the simulation. Why is this happening and how do I actually assign an value to them?
All signals in verilog simulation are initialized to 'x'. So are the values of A and D. Your second xor is applied to xoy ^ A. Since A is x, the result of this xor is always x. you need to break this loop, as oldfart suggested.
The usual way for doing it is to introduce a reset in the flop, synchronous or asynchronous. Here is an example of a synchronous reset flop:
always #(posedge clk)
if (reset)
q <= 0;
else
q <= D;
So, now, if you set your reset to '1' for at least one posedge of clk and then set it to '0', you will break the loop by pushing a non-'x' value in the data path.
You do not clear your D-FF. The output is X at the start and as you use that in a feedback loop it stays X.
This: wire state=1'b0; does not clear you FF. You have to clear 'q'.
I have an inverter with X input when my testbench start. So my output is X too.
Can i force my output is 1 or 0 when my input is X?
Thank you.
Sure you can. If your inverter is a module instance, simply force the wire that is tied to the output. If it is just an assign statement, just force the wire that's being assigned to.
module tb();
reg l_a;
wire l_q;
invtr i0(.q(l_q), .a(l_a));
initial begin
$vcdpluson;
#10;
force l_q = 1'b0;
#10;
release l_q;
#10;
l_a = 1'b0;
#10;
l_a = 1'b1;
#10
$finish;
end
endmodule
module invtr (output wire q,
input wire a);
assign q = ~a;
endmodule
The force of the output happens at time 10ns and the release happens at time 20ns. During this time the value is 0.
No.
An X value is the result of an error; it does not represent any well-defined value. Performing any kind of operation on such a value will also result in an unpredictable value -- another X.
You will need to figure out what is causing this error and fix it.
Not possible for an inverter. Providing an input X will always inherently give an output X.
I have Altera DE2-115 FPGA and I try to self-learn Verilog. I decided to make a smoke detector and whenever it smells smoke the buzzer rings (the smoke detector outputs a digital signal).
Here is my trial :
module fire(flag,clock,reset,fire,fire_state,firealarm);
input clock, reset, flag, fire;
output [2:0] fire_state;
output firealarm;
wire fire;
reg [2:0] fire_state;
assign firealarm = (fire_state == 1) ? (flag ? 0 : 1) : 0;
always # (posedge clock)
fire_state<= fire ? 1: 0;
end module
But it doesn't run and I think there are a lot of logic errors in this code, any help please? :)
endmodule is one word, you need to remove the space.
Almost all simulators these days support verilog-2001 or greater so I would encourage the use of the modern port style (ANSI) and not the old verilog 1995 style.
Your port list goes from:
module fire(flag,clock,reset,fire,fire_state,firealarm);
input clock, reset, flag, fire;
output [2:0] fire_state;
output firealarm; wire fire;reg[2:0] fire_state;
to :
module fire(
input clock,
input reset,
input flag,
input fire,
output reg [2:0] fire_state,
output firealarm
);
I have placed each port on a new line with it direction, this makes it much easier to maintain code, it also make it a lot more readable and therefore minimises the chance of typos in connections.
You have used this syntax a lot (flag?0:1), where you using a boolean to select a boolean there is no need to do this and makes it more difficult to read. If you need to invert it then is a bitwise invert (~). However it is not clear what you are using flag for.
for comparrisons and assignments you should be including the width.
assign firealarm = (fire_state == 3'b1)? (~flag) : 1'b0;
This could also be written out in a combinatorial always block:
always #* begin
if (fire_state==3'b001) begin
firealaram = ~flag;
else begin
firealaram = 1'b0;
end
end
fire is 1 bit, fire_state is 3 bits.
always # (posedge clock) begin
fire_state <= {2'b0, fire};
end
I am trying to wrap my head around a mix of combinational and behavioral logic. I've got small FPGA with 4 LEDs and a 66 MHz clock input. The idea was to make two of them glowing (one rising, one falling) and another two blinking. So I came up with the following code:
module ledflash(input wire CLK,
input wire USER_RESET,
output wire LED[3:0]);
reg [26:0] cnt;
reg [4:0] pwm;
wire led_enable = ~USER_RESET;
always #(posedge CLK)
begin
if (led_enable)
begin
cnt <= cnt + 1;
pwm <= pwm[3:0] + (cnt[26] ? cnt[25:22] : ~cnt[25:22]);
end
else
begin
cnt <= 0;
pwm <= 0;
end
end
assign LED[0] = led_enable ? (cnt[26] ? pwm[4] : ~pwm[4]) : 0;
assign LED[1] = led_enable ? (cnt[26] ? ~pwm[4] : pwm[4]) : 0;
assign LED[2] = led_enable ? cnt[25] : 0;
assign LED[3] = led_enable ? ~cnt[25] : 0;
endmodule
I did not want to use a vendor specific DCM, and so simple bit adders with 66MHz clock works out the magic. Perhaps the whole design is wrong in a first place (for instance, I could have used two clock dividers and simply flip a bit of two registers to achieve (almost) the same thing), but I ran into this situation which made me wondering...
From a regular software developer's point of view, there are some parts in continuous assignments that seem redundant. For example, an extra register can be used and so it would seem that less work is performed. For instance:
module ledglow(input wire CLK,
input wire USER_RESET,
output wire LED[3:0]);
reg [26:0] cnt;
reg [4:0] pwm;
reg led_pair1;
reg led_pair2;
wire led_enable = ~USER_RESET;
always #(posedge CLK)
begin
if (led_enable)
begin
cnt <= cnt + 1;
pwm <= pwm[3:0] + (cnt[26] ? cnt[25:22] : ~cnt[25:22]);
end
else
begin
cnt <= 0;
pwm <= 0;
end
led_pair1 <= cnt[26] ? pwm[4] : ~pwm[4];
led_pair2 <= cnt[25];
end
assign LED[0] = led_enable ? led_pair1 : 0;
assign LED[1] = led_enable ? ~led_pair1 : 0;
assign LED[2] = led_enable ? led_pair2 : 0;
assign LED[3] = led_enable ? ~led_pair2: 0;
endmodule
I was trying to dig into synthesizer report differences for two approaches above and look at HDL schematics, but it way too complex for such an inexperienced guy like me.
No doubt synthesis tool optimizes the combinational logic very well, but assuming the the right hand side expressions are very complicated to be one-liners etc, is there a way to say something like this?
if (some_reg_var) begin
assign net0 = 1;
assign net1 = 0;
end
else
begin
assign net0 = 0;
assign net1 = 1;
end
Or does it even make sense to do so? If not, does it make sense to introduce registers in such cases to simplify the behavioral part? I am sure there are some rules or thumb at least. Any help is appreciated.
Your question is a bit verbose, but I think I understand what you're getting at (correct me if I'm wrong).
You wish to know if there is a way to break up long assign statements to use if/else logic, similar to regs in an always block?
Verilog always seemed slightly funny to me in this way, but just because you declare something a 'reg' datatype does not mean that it gets synthesized to a register. It only actually creates a register if there is some state to store. Having said that, the following two statements should synthesize to exactly the same thing:
Case 1:
wire a;
wire b;
assign a = b ? 0 : 1;
Case 2:
reg a;
wire b;
always #(b)
if(b)
a <= 0;
else
a <= 1;
Both of these should create the exact same logic (simply, an inverter with a = !b). Even in the second case where you have declared a reg, it doesn't actually instance a register, because there's nothing to remember (all of the inputs are in the sensitivity list).
Because of this, you are free to write complex if/else logic to simplify your code, and this doesn't mean you're paying a penalty of synthesizing extra registers. So feel free to write it which ever way is most comfortable for you. (If you do use an always block, make sure to have an assignment for all possible cases, or you will infer a latch which you probably don't want).