need help with event expression evaluation and posedge

[Mike]

Hello,

9.7.2 (Event control) says:
"If the expression evaluates to more than a 1-bit result, the edge
transition shall be detected on the least signifcant bit of the
result. The change of value in any of the operands without a change
in the value of the least signifcant bit of the expression result
shall not be detected as an edge."

so why do I see my "should not see this" messages? I don't have
any X/Z running around in the design, so the least significant bit
in the event_expression (count & 3'b100) is always 0.

Thanks in advance,
Mike

------------- source file -------------------------
module counter;
reg clk;
reg rst_n;
reg [2:0] count;

initial
begin
clk = 1'b0;
rst_n = 1'b0;
count = 3'h0;
rst_n <= #2 1'b1;
forever clk = #1 !clk;
end

initial
#100 $finish;

always @(posedge clk)
count <= {3{rst_n}} & (count + 1'b1);

always @(count & 3'b100)
$display("should see this");

always @(posedge(count & 3'b100))
$display("should not see this");

always @(negedge clk)
$display("time:%d, count=%d", $time, count);
endmodule

--------log file------------------------------
Tool: VERILOG-XL 05.30.002-s Jan 18, 2006 16:46:05

Compiling source file "mike.v"
Highest level modules:
counter

time: 2, count=0
time: 4, count=1
time: 6, count=2
time: 8, count=3
should see this
should not see this
time: 10, count=4
time: 12, count=5
time: 14, count=6
time: 16, count=7
should see this
time: 18, count=0
time: 20, count=1
time: 22, count=2
time: 24, count=3
should not see this
should see this
time: 26, count=4
time: 28, count=5
time: 30, count=6
time: 32, count=7

 

Because when they wrote the standard, they thought that this is what
Verilog-XL did, but they were wrong. Verilog-XL uses the "truth value"
of the multi-bit value, much like an if-statement would. If the value
is all zero, then it is regarded as false or low. If any bits are 1,
then it is regarded as true or high. A transition from low to high
(all-zero to not-all-zero) is a posedge. A transition from true to
false (not-all-zero to all-zero) is a negedge. The description gets a
little more involved when X/Z are included. Essentially, you take the
reduction-OR of the bits and apply the edge rules to that.

Since the standard did not correctly describe what XL did, all other
simulators were left with a problem. They could match XL, to get
backward compatibility, or match the official standard. I suspect that
most later simulators eventually ended up matching the standard. But
XL, unsurprisingly, continues to match XL.

Your best bet is to stop relying on this obscure behavior. If you want
to check for an edge on the least significant bit, then use an
expression that only includes that bit. If you want the XL behavior,
then do an explicit reduction-OR on the bits. This will make your code
portable, and also comprehensible to a reader who doesn't know this
obscure rule in the standard.

And if you are trying to implement a Verilog tool, so you need to know
what rule to use, then you have a problem. You have to make a decision
between the de facto and de jure standards, just like every other
implementor since this inconsistency was created.

 

[Mike]

Yes, it's for a tool, so I guess I'll have to choose one or implement
both
and let the user choose.

I don't have access to any other simulators, but now I am curious as to
what they produce for simulation output...

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike wrote:

Yes, it's for a tool, so I guess I'll have to choose one or implement
both
and let the user choose.

I don't have access to any other simulators, but now I am curious as to
what they produce for simulation output...

Icarus Verilog uses the "documented" behavior of following only the
bottom bit, and I've heard no complaints.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD0AU6rPt1Sc2b3ikRAp8BAJ0bsHTJ9ohCbQuBtTtsk2dkO9GsVACgo18b
DXSNqp+ZmRNjjJXYbbNAT3A=
=f9Q6
-----END PGP SIGNATURE-----

 

[Kim Enkovaara]

Mike wrote:

Yes, it's for a tool, so I guess I'll have to choose one or implement
both
and let the user choose.

I don't have access to any other simulators, but now I am curious as to
what they produce for simulation output...

For Modelsim 5.8 and 6.1 the output is

# Loading work.counter
# time: 0, count=0
# should see this
# time: 2, count=0
# time: 4, count=1
# time: 6, count=2
# time: 8, count=3
# should see this
# time: 10, count=4
# time: 12, count=5
# time: 14, count=6
# time: 16, count=7
# should see this
# time: 18, count=0
# time: 20, count=1
# time: 22, count=2
# time: 24, count=3
# should see this
# time: 26, count=4
# time: 28, count=5
# time: 30, count=6
# time: 32, count=7
# should see this

--Kim

 

[Rob Dekker]

ModelSim also uses the LRM interpretation, and so do a multitude of other tools
I'm getting this kind of warnings from other tools :

event_sim.v(24): WARNING: edge of vector is only sensitive to the LSB (VERI-1222)


"Mike" <hammeron56@yahoo.com> wrote in message news:1137696178.355412.323570@g47g2000cwa.googlegroups.com...

Yes, it's for a tool, so I guess I'll have to choose one or implement
both
and let the user choose.

I don't have access to any other simulators, but now I am curious as to
what they produce for simulation output...