Re: [sv-bc] Verilog Std Ambiguity

I don't think the LRM is merely ambiguous here.  I would contend that it
is wrong.  Neither interpretation matches what Verilog-XL actually does,
and there is probably a fair amount of legacy code out there that would be
affected by changing this behavior.

There was a similar previous situation like this, involving the meaning
of a posedge/negedge applied to a vector.  The LRM said that it was based
on the LSB, while Verilog-XL based it on whether the overall value was
0 or not (effectively performing a reduction-OR to the bits before checking
for the edge).  In this case, it was decided to keep what was in the LRM.
Legacy code wasn't a big issue, since applying a posedge/negedge to a
vector value was unusual.

It may not be terribly common to have rise/fall delays on continuous
assignments to vectors, but I expect it is more common than an edge
applied to a vector.  So I think the LRM should conform to the "de facto"
standard in this case.

Oddly, in this case the situation seems to be reversed from the edge case.
Interpretation II of the LRM text bases the delay on whether the overall
value goes to 0 or not.  Verilog-XL appears to base the delay on the LSB.
If the new value of the LSB is 0, it uses the falling delay.  If the new
value of the LSB is 1, it uses the rising delay.  If the new value of the
LSB is z, it uses the turn-off delay.  (The LRM text is particularly
unclear about what it means to make the output z).

So changing the LRM to use the LSB would also make it consistent with
the edge definition.  The rising delay would be used in the same cases
that are considered a posedge on the vector.  The falling delay would be
used in the same cases that are considered a negedge on the vector.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.