Observed a bug in the Model sim V 6.0a

V

vssumesh

Guest
Hi all,
I did observed a problem in the model sim. I was simulating a code
similar to the one given below.

module a (input a, output b);
wire local_variable c;
assign c = a;
tasks .....
..........
always @(*)
begin
..........
..........
end
endmodule

But the assignment c=a is not working some times. It always works if i
declare it as a reg and include it in the always block. But this will
not work if i use it part of the assign statement. the intresting part
of it is that it will not work in the first pass. At the second time
the execution enters the loops it simply executes. I can sidestep the
problem by declaring it as a reg but i want to know the reason. Did any
of you observed similar problems. Is this due to any knid of bug in the
modelsim.
regards
Sumesh V S
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

vssumesh wrote:
Hi all,
I did observed a problem in the model sim. I was simulating a code
similar to the one given below.

module a (input a, output b);
wire local_variable c;
assign c = a;
tasks .....
..........
always @(*)
begin
..........
..........
end
endmodule

But the assignment c=a is not working some times. It always works if i
declare it as a reg and include it in the always block. But this will
not work if i use it part of the assign statement.
Click to expand...
You've most likely got a race condition. I suspect that you are
trying to assign a value to a and notice the value appearing in c.
But the assignment is not instantaneous, it is schedule to happen
in the current time step, but schedule all the same.

- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEA+SwrPt1Sc2b3ikRAr6TAJ93UUAS9slHcSS/CZWT/3afJ6CaKACfWu4P
VfJxly8q4kG8jgRHDUPFbbg=
=5uvm
-----END PGP SIGNATURE-----
 
This is problem of Verilog 2001. Each simulator do the same.
It is fixed in System Verilog.
 
So this cant be corrected?? please give me some details on this
issue....
 
michaelst@gmail.com wrote:
This is problem of Verilog 2001. Each simulator do the same.
It is fixed in System Verilog.
Click to expand...
Rubbish. It is most likely a problem with the OP's source code,
assuming I understand his complaint properly. See the following
example code that makes my point.


module main;

reg bar;
wire foo = bar;

initial begin
bar <= 1;
$display("Note that foo is still no 1 here: %b", foo);

#1 $display("The delay allows assignment event to propagate: %b",
foo);

bar = 0;
$display("This is a race. foo might or might not be 0: %b", foo);

#1 $display("Now it certainly will be 0: %b", foo);
end // initial begin
endmodule // main


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
Steve,

It is actually possible to have a problem like this. It is a classic
race condition at time 0 between the initial value of 'c' getting set
and the always block running the first time and starting to wait at the
@* event control.

Having a problem would require that the original source of the value of
'a' is being set by an initial block using a blocking assignment at
time 0 (or otherwise being set to a known value at time 0 somehow). It
also requires that the simulator is running that initial block,
propagating it through the port to 'a', evaluating the continuous
assignment to 'c' and updating the value of 'c', all before it starts
executing the always block for the first time. That seems unlikely, so
that may not be the real reason, but it is possible (and is legal by
the standard).

Note that it is incorrect to say that all simulators will do that.
Some implementors have made choices that ensure they avoid this
problem.
 
sharp@cadence.com wrote:
It is actually possible to have a problem like this. It is a classic
race condition at time 0 between the initial value of 'c' getting set
and the always block running the first time and starting to wait at the
@* event control.
Click to expand...
I know that. I was point out to the OP (with an example) that these
are in fact races. An intermediate poster tried to claim that there
was some mythical "language bug", and I tried to show how a bad source
program could have the OP's symptoms. Yes, my little example has
several races.

Note that it is incorrect to say that all simulators will do that.
Some implementors have made choices that ensure they avoid this
problem.
Click to expand...
Been there, done that, have the scars to prove it:) In fact,
Icarus Verilog will detect that an always block is combinational
and will schedule its first execution near the end of time-0
in order to catch initial sets. Not something that a Verilog
programmer should rely on, and certainly not the only source
of races in the OP's case.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
Unfortunatelly it's true. You could read any SystemVerilog spec and
compare "always @*" and "always_comb".
 
michaelst@gmail.com wrote:
Unfortunatelly it's true. You could read any SystemVerilog spec and
compare "always @*" and "always_comb".
Click to expand...
So you're saying that System Verilog's operation differs from Verilog's
given identical code?

If so, then I'm not interested.

-a
 
michaelst@gmail.com wrote:
Unfortunatelly it's true. You could read any SystemVerilog spec and
compare "always @*" and "always_comb".
Click to expand...
That changes the scheduling of the "always" at time-0, but it
does not change the fact that an assignment into a net then
takes time to propagate through the gates. For example:

wire foo = ~bar;
initial begin bar = 0; $display("bar=%b, foo=%b", bar, foo); end

.... is a race and in many Verilog (and yes, SystemVerilog too)
compilers you are going to get unexpected results.

The nature of the OP's (very vague) description suggests to me
that it's not a scheduling of the always block, but somehow
getting in between a changing and c=a changing. It can happen
if there are blocking assignments floating around.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
I was just watching the points you are suggesting ( iam only a
beginer), So you are saying that it is an unpredictable situation (as
in the example given above). But how can get around this problem.
The nature of the OP's (very vague) description suggests to me
that it's not a scheduling of the always block, but somehow
getting in between a changing and c=a changing. It can happen
if there are blocking assignments floating around.
Yes it is not caused by the always block but by an assignment
Click to expand...
statement. But why the change in the variable a (in your example) is
reflected immediately in the variable c.
regards
Sumesh V S
 
michaelst@gmail.com wrote:
Unfortunatelly it's true. You could read any SystemVerilog spec and
compare "always @*" and "always_comb".
Click to expand...
So you're saying that System Verilog's operation differs from Verilog's
given identical code?

If so, then I'm not interested.

-a
 
This is other type of "always". The classic always is the same for all
versions of verilog.
 
If someone believes that using @* was supposed to make an always block
match combinational logic as well as a continuous assignment does, then
they could claim that its failure to match this aspect is a "language
bug."

Always blocks were not originally designed to model purely
combinational logic. That is what continuous assignments were designed
for. However, a so-called "combinational always block" does a pretty
good job. It has a couple of weaknesses compared to a continuous
assignment: you have to explicitly specify the full list of inputs to
wait on, and it may not produce the right value at the start if the
inputs are initialized to non-X values at time zero (including if all
of them are constants). The @* construct was designed to solve the
first weakness. It was not designed to solve the second. Whether that
is a "language bug" depends on whether you think it was supposed to.

The SystemVerilog always_comb construct solves the second weakness
also. It does this by specifying that body of the block will always
execute at time zero (this is equivalent to treating the implicit event
control as if it appears at the end of the block instead of the
beginning). There is also a rule that it must evaluate after the
initial blocks have evaluated, which seems to have been added to try to
help out, but isn't necessary and doesn't really help any.
 
On 4 Mar 2006 18:23:24 -0800, sharp@cadence.com wrote:

If someone believes that using @* was supposed to make an always block
match combinational logic as well as a continuous assignment does, then
they could claim that its failure to match this aspect is a "language
bug."

Always blocks were not originally designed to model purely
combinational logic. That is what continuous assignments were designed
for. However, a so-called "combinational always block" does a pretty
good job. It has a couple of weaknesses compared to a continuous
assignment: you have to explicitly specify the full list of inputs to
wait on, and it may not produce the right value at the start if the
inputs are initialized to non-X values at time zero (including if all
of them are constants). The @* construct was designed to solve the
first weakness. It was not designed to solve the second. Whether that
is a "language bug" depends on whether you think it was supposed to.

The SystemVerilog always_comb construct solves the second weakness
also. It does this by specifying that body of the block will always
execute at time zero (this is equivalent to treating the implicit event
control as if it appears at the end of the block instead of the
beginning). There is also a rule that it must evaluate after the
initial blocks have evaluated, which seems to have been added to try to
help out, but isn't necessary and doesn't really help any.
Click to expand...
[not quite on-topic for this newsgroup]

A VHDL process 'runs' whenever there's a change on any of the signals
in its sensitivity list. It also runs at time 0, making it similar to
the SystemVerilog always_comb. (Actually, it's the other way around -
VHDL has been doing this since the '87 language definition.)
The VHDL process still doesn't have the equivalent of @* yet, although
that's likely to be added in the next language revision.

Regards,
Allan
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top