Here is the code
module m;
bit x;
initial
begin
fork
begin
wait(x == 1);
wait(x == 0);
end
begin
#(x == 1);
#(x == 0);
end
#10 $display("Timeout");
join_any
disable fork;
end
initial
begin
#5;
x = 1;
// Some other Logical Stuff
x = 0;;
end
endmodule
Now in this code, Timeout will happen, because x = 1 & x = 0 is done in the single time step.
One solution is to provide delay between x = 1 & x = 0, then both waits will work fine.
Is there any other method, which can work without providing hard-coded delays?
Note :- With events or semaphores like stuff, this problem can be solved. But I am looking for the answer in terms of coding style or methods, which can work without usage of events.
There are several ways, which you can use here like event, semaphore, flag, etc.
I have added an event in your code. Please find a modified code in below link.
http://www.edaplayground.com/x/Ws3
There are other ways also like,
1. Assign value "1" to x, during its declaration
E.g., bit x=1;
2. Use blocking and nonblocking assignment together in your 2nd initial block.
E.g.,
initial
begin
#5;
x = 1;
// Some other Logical Stuff
x <= 0; // Add non-blocking assignment
end
end
=> The second option is not a good coding practice, but it'll solve your issue as both the assignment statments will work on different regions.
Related
The output of this executable is x until you remove d from the c assignment. The output is x x x x. When d is removed from the assignment, the output is as expected "2 3 4 5".
module test();
logic [1:0] a, b, d;
logic [2:0] c;
assign c = a+b+d;
initial begin
d = 0;
a = 1;
b = 1;
$display(c);
a = 2;
b = 1;
$display(c);
a = 2;
b = 2;
$display(c);
a = 2;
b = 3;
d = 3;
$display(c);
end
endmodule
Both outputs are valid, you have a race condition.
A continuous assign statement is a concurrent process that waits for signals on the RHS to change, then evaluates the expression and makes the assignment.
The initial block is another concurrent process. As you procedurally make assignments to each signal, the scheduler is free to jump to to the other process and execute it, ... or it can continue executing statements until hitting a blocking delay, or it terminates.
If fact, many tools in-line continuous assignments as an optimization, only executing them when the lhs gets referenced. That could be what's happening here when you remove d from the rhs.
Your problem is in understanding verilog simulation. It is an event-driven flow.
In your case assignment to 'c' happens when any input to the assign statement change.
But the change will be detected only when execution of the non-timed chunk in your initial block is done. And this chunk ended with the last statement.
So, as a result, all your $display(c) will show the value of 'c' as it existed before the initial block starts execution. In order to see updates, you need let the code wait till the changes have a chance to propagate. A simple example would be the following:
initial begin
d = 0;
a = 1;
b = 1;
#1 $display(c);
a = 2;
b = 1;
#1 $display(c);
a = 2;
b = 2;
#1 $display(c);
a = 2;
b = 3;
d = 3;
#1 $display(c);
end
Adding #1 before every $display will let the changes to propagate and display expected results.
There is a gray area in interpretation of the code like yours. Note that the initial block has a, b, and d as the output. In the sequential code with no timing control constructs it just re-assigns the values of those outputs. For simulation semantics only the lastly assigned values matter and should trigger an event. However, it looks like some simulators might interpret it differently and trigger events whenever the value changes. This is up to the simulator implementation in this case. For example, as i noticed, VCS does trigger events for every change, but only in some cases. NC does not trigger those events.
I guess you can interpret the simulation behavior as undefined for this kinds of the code. To make it deterministic, use correct timing controls, as in the example above.
hi guys i wrote a while loop inside a for loop but it is not working is there something wrong with my coding?
always# (posedge clk) begin
if (delay)
D = 1;
else
D = 0;
if (a) begin
for (g=0;g<10;g=g+1) begin
high <= high_in;
low <= low_in;
delay = 0;
while (count == 0) begin // when i simulate the waveform cant come
out and it stuck at here
ws = 1;
count <= D;
delay = 1;
end
delay = 0;
end
end
else begin
//other coding
end
end
If you enter the while loop when count is zero, you have an infinite loop. You've got a non-blocking assignment on count, so it won't update. Look up blocking vs. non-blocking assignments.
I find some basic issues with this code :-
1. Mix and match of blocking and non-blocking in same always block.
2. use of blocking statement in a always block is a problem creator
3. No reset/default value of count, delay outside of loop. although decision making is based on that.
Few advice :-
Try to use for and while loop outside always statement.
try to assign default values for the loop usage.
As suggested by EML, try writing it again. Try to not combine different assignment as far as possible.
This seems like it would be simple, but I can't find out how to do this anywhere... All I want to do is add 1 to a 4 bit wire.
Overall, I want to count the number of 1's in a 8 bit variable. Let's call this input inA. The output will be outA. Both are defined as wires; inA is 8 bits where outA is 4 bits.
wire[0:7] inA;
wire[0:3] outA;
I can do a for loop to go through the array:
for (i = 0; i <= 7; i = i + 1) begin
if (inA[i] == 1) begin
outA <= outA + 1;
end
end
But this isn't working.
Can someone please help? I am extremely new to Verilog (and VHDL), so I really have no clue what I am doing wrong.
There are a few ways to do this, here is one option:
reg [0:3] ones;
integer i;
always # (inA) begin
ones = 0;
for (i = 0; i < 8; i = i + 1) begin
ones = ones + inA[i];
end
end
assign outA = ones;
Since you haven't provided your full source code (e.g. the context of the for loop), we can only guess what the problem with that is.
Remember though that non-blocking assignments like outA <= outA + 1 will be scheduled to be executed at the end of the always block, such that the last assignment will override all previous ones.
Since outA (which by the way will have to be a reg if your for loop is embedded in an always block), is only updated after the always block has finished "executing", only inA[7] can cause an increment to outA.
Have a look at my answer here for further information on how always blocks are executed.
I am new to verilog.I dont know what the hell is wrong with my code.The program displays the counter value at the given moment from 0H to 16H.
key[2] is the button that will increment the counter, and sw[0] resets the counter.
else if(sw[9:5]==5'b00100)
begin
counter = 0;
hex2 = 7'b1000000;
always#(negedge sw[0],posedge key[2])
begin
if(~sw[0]) counter = 0;
else if(key[2])begin
if(counter == 16'hFFFF) counter = 0;
else counter = counter +1;
end
end
end
The error I get says Verilog HDL syntax near text "always"; expecting ";", or "#", or "end" or an identifier("always" is a reserved keyword), or a system task, or "{", or a sequential statement.
my counter = 0; is defined at the top outside my upper most module as integer counter;
Your help is greatly appreciated.
always block is not allowed in sequentially executed if..else block.
One way you can try is :
#(negedge sw[0],posedge key[2])
This will trigger on any change in above two signals, but it will detect only one change.
Looks like you want to enable the counter when sw[9:5]==5'b00100
Why not try setting a flag here, and then use an always #flag block to implement the running counter.
I am somewhat new to Verilog. I know that in a Clock Process we should use non blocking assignments, and in a Non Clock processes, we use blocking assignments.
I have came across this code, when I was reading someone else's code.
reg iowrb_int,iowrb_met;
reg iordb_int,iordb_met;
always#(*)
begin
iowrb_int <= iowrb_met;
iordb_int <= iordb_met;
iowrb_met <= iowr_bar;
iordb_met <= iord_bar;
end
I am really not sure about the above code ! I don't think it is doing any registering, correct? Would it mean anything to have a non-blocking in a always#(*) statement ?
Is there any difference in using blocking vs non-blocking in a always#(*) statement ?
The main difference is:
a blocking assignment is executed before the next assignment i.e. it blocks the execution of the next statement.
non-blocking assignments execute in parallel i.e. they don't block the execution of the statement following them.
Suppose a = 2 and b = 3 then non-blocking assignments:
a <= 4;
b <= a;
results in a = 4 and b = 2 - value of a before assignment
But
a = 4;
b = a;
Will result in a=4 and b=4 - value of a after the blocking assignment completes.
A variable getting synthesized to a register (latch or flip-flop) vs. combinatorial logic depends on the sensitivity list of the always block. It does not depend on use of blocking or non-blocking assignment.
For example:
always #(*) begin
if (enable)
q = d;
end
This will result in a D-latch since assignment to q is not specified for when enable==0 so it needs to remember is last assignment.
While
always #(*) begin
if (enable)
q = d;
else
q = f;
end
This will result in a mux (combinatorial logic) since assignment to q is specified for both cases of enable and so q need not remember anything.
The blocking vs non-blocking is so that your gate level (synthesis) matches your RTL simulation. Using a different one to alter the behaviour of the simulation as far as I know will not effect synthesis and therefore the behaviour of gate-level.
<= non-blocking effectively take a temporary copy of the copy right-hand side, and make the = blocking assignment at the end of the timestep.
a <= b;
b <= a;
is equivalent to:
a_temp = b;
b_temp = a;
//
a = a_temp;
b = b_temp;
The example uses combinatorial logic, that is it contains no state, so all inputs must be defined by all outputs.
always#* begin
iowrb_int <= iowrb_met;
iordb_int <= iordb_met;
iowrb_met <= iowr_bar;
iordb_met <= iord_bar;
end
When the right hand side updates the block should be retriggered. Since iowrb_met is on both sides I am not sure what this implies interms of electrical connectivity.
while <= implies copying to a temp location, combinatorial logic does not have this capability, it is always and continuously driven by the assignment.
I think in simulation you effectively have this:
always#* begin
iowrb_int_temp = iowrb_met;
iordb_int_temp = iordb_met;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
iowrb_int = iowrb_int_temp;
iordb_int = iordb_int_temp;
end
In hardware you would have:
always#* begin
iowrb_int = iowrb_met; //= iowr_bar;
iordb_int = iordb_met; //= iord_bar;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
end
Where iowrb_int is effectively the same as iowrb_met
Flip-flops are implied using always #(posedge clk
Combinatorial logic is implied using always #* but latches can be implied when the output is not fully defined from inputs.
By only changing to code to blocking assignments it may synthesize to latches and/or create logical equivalency check mismatches depending on the tools handle.
This is how it looks through the scheduler:
With blocking:
The *_int signals are assigned
The *_met signals are assigned
Move on to the next time step.
*_int keeps the non-updated values of *_met
With non-blocking:
The *_int signals are assigned
The *_met signals are assigned
A change to *_met is detected causes a loop back the the Active region of the scheduler
Re-assign the *_int signals
Re-assign the *_int signals
Move on to the next time step.
*_int has the same values as *_met
Waste CPU time to reprocessing. This is not important on a small project, but can add noticeable overhead used throughout a large project.
The correct, logical equivalent, and CPU friendly way would be to revers the assignment order (assign *_met before *_int):
always#(*)
begin
iowrb_met = iowr_bar;
iordb_met = iord_bar;
iowrb_int = iowrb_met;
iordb_int = iordb_met;
end
The *_int signals are assigned
The *_met signals are assigned
Move on to the next time step.
*_int has the same values as *_met
OR use *_bar as the assigning value (i.e. if a==b and b==c, then a==b and a==c):
always#(*)
begin
iowrb_int = iowr_bar;
iordb_int = iord_bar;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
end
The *_int and *_met signals are assigned
Move on to the next time step.
*_int has the same values as *_met
As others have said, changing to blocking assignments here will actually not work. Using blocking assignments in combinational always blocks (which is the recommendation) require you to put assignments in the right order.
Using non-blocking assignments in combinational always blocks may seem attractive, because you can then have assignments in any order, like in VHDL. Besides performance, one good reason to avoid this is that it doesn't work with always_comb. This code does not work:
always_comb begin
tmp <= in;
out <= tmp;
end
The reason is that tmp will not be part of the sensitivity list. It will work as expected if you use always #(*), always #(tmp, in) or replace with blocking assignments.