Verilog operator precedence

[Sergei Sokolov]

Netters,
I have recently come across a curious discrepancy in how
Verilog operator precedence is determined.

The table in the draft LRM (I do not have the IEEE standard LRM)
of April 1995 showing operator precedence (Table 4-4 p. 4-4)
promises to show *binary* operator precedence but lumps all
(binary and unary) operators together which greatly confuses the matter,
especially in cases when both unary and binary operators have the
same symbol (e.g. ^~).

The table of precedence in Thomas and Moorby (2nd edition)
is DIFFERENT from both the aforementioned Table 4-4 and
a corresponding table in Verilog LRM 2.0, but makes more
sence and clearly articulates unary vs. binary operators.

Where is the truth?

I'm primarily concerned with bit-wise and unary reduction operators.

Thanks,

Sergei Sokolov
ASC
sok...@ascinc.com

[Celia C.]

In article <326BA093...@ascinc.com>,

Sergei Sokolov <sok...@ascinc.com> wrote:
>Netters,
>I have recently come across a curious discrepancy in how
>Verilog operator precedence is determined.
>
>

>The table of precedence in Thomas and Moorby (2nd edition)
>is DIFFERENT from both the aforementioned Table 4-4 and
>a corresponding table in Verilog LRM 2.0, but makes more
>sence and clearly articulates unary vs. binary operators.
>

I have found that it is best to put the parenthesis to force the
precedence. Otherwise you risk getting different results with
different tools.

--
-----------------------------------------------------------------------------
--Celia Clause Celia's Verilog/EDA web page:
cel...@teleport.com http://www.teleport.com/~celiac/ver_eda.html

[Gerard M Blair]

I am quoting a direct mail to me regarding my last posting

Sergei Sokolov wrote:
> thank you for the reply. The point of my question was a little
> broader, namely that the said table does not help you when you want
> to determine the precedence of two *different* operators, say,
> unary ^~ and binary &:

> ^~ a & b.

I have trouble answering this (AND NEED HELP PLEASE)
because:

1) I think the precedence table is clear in that & has a higher
precedence than ^~ so that (^~ a & b) == (^~ (a & b))

2) Verilog-XL disagrees

module testPrec;
reg [3:0] a,b;

initial begin
a = 4'b1010;

b = 4'b0011;

$displayb(^~ a);
$displayb(a & b);
$displayb(^~ a & b);
$displayb(^~ (a & b));
$displayb((^~ a) & b);
end
endmodule // testPrec

gives

1
0010
0001
0
0001

So - is the precedence table incomplete? or is my reading of
the draft spec wrong? or is Verilog-XL 9404 wrong?

Gerard M Blair, Senior Lecturer, The Department of Electrical Engineering,
The University of Edinburgh, Scotland, UK
Email: ger...@ee.ed.ac.uk - Home page: http://www.ee.ed.ac.uk/~gerard/

[Gerard M Blair]

Sergei Sokolov wrote:

> The table in the draft LRM (I do not have the IEEE standard LRM)
> of April 1995 showing operator precedence (Table 4-4 p. 4-4)
> promises to show *binary* operator precedence but lumps all
> (binary and unary) operators together which greatly confuses the matter,
> especially in cases when both unary and binary operators have the
> same symbol (e.g. ^~).

Yes - the draft IEEE says
-----------------------------------
| Operator | Precedence |
-----------------------------------
| + - ! ~ (unary) | highest |
| * / % | |
| + - (binary) | |
| << >> | |
| < <= > >= | |
| == != === !== | |
| & ~& | |
| ^ ^~ | |
| | ~| | |
| && | |
| || | |
| ?: (conditional) | lowest |
-----------------------------------

But there should be no confusion as all but the last entry
associate left to right thus:

module testPrec;
reg [3:0] a,b;

initial begin
a = 4'b1010;

b = 4'b0010;

$displayb(a ^~ b);
$displayb(^~ a ^~ b);
$displayb(^~ (a ^~ b));
$displayb((^~ a) ^~ b);
end

endmodule // testPrec

gives

0111
1100
0
1100

This demonstrates that the left most ^~ is applied first in the
expression ^~ a ^~ b and so is equivalent to (^~ a) ^~ b
which is clear provided you realize that (^~ a) == 1'b1 which
in a four bit expression is expanded to 4'b0001.

--

[Mitchell Perilstein]

Gerard M Blair wrote:
> So - is the precedence table incomplete? or is my reading of
> the draft spec wrong? or is Verilog-XL 9404 wrong?

Who ever said XL corresponds with 1364? The current state of 1364
pretty much guarantees that no tool can comply.

In fact, for cases where the spec and XL differ, why should an
industrial tool follow the spec? Who would want to buy an industrial
tool that handles Verilog differently from XL?

Mitchell Perilstein
mperi...@miworld.net

[Sergei Sokolov]

Gerard M Blair wrote:
>
> I am quoting a direct mail to me regarding my last posting
>
> Sergei Sokolov wrote:
> > thank you for the reply. The point of my question was a little
> > broader, namely that the said table does not help you when you want
> > to determine the precedence of two *different* operators, say,
> > unary ^~ and binary &:
>
> > ^~ a & b.
>
> I have trouble answering this (AND NEED HELP PLEASE)
> because:
>
> 1) I think the precedence table is clear in that & has a higher
> precedence than ^~ so that (^~ a & b) == (^~ (a & b))
>
> 2) Verilog-XL disagrees
>

> module testPrec;
> reg [3:0] a,b;
>
> initial begin
> a = 4'b1010;
>

> b = 4'b0011;
>
> $displayb(^~ a);
> $displayb(a & b);
> $displayb(^~ a & b);
> $displayb(^~ (a & b));

> $displayb((^~ a) & b);

> end
> endmodule // testPrec
>
> gives
>

> 1
> 0010
> 0001
> 0
> 0001
>

> So - is the precedence table incomplete? or is my reading of
> the draft spec wrong? or is Verilog-XL 9404 wrong?
>
>
>

> Gerard M Blair, Senior Lecturer, The Department of Electrical Engineering,

Based on the information obtained from "private sources" (a member
of the 1364 WG) I concluded that the TAble 4-4 is, indeed,
wrong, and, maybe, the table in Thomas and Moorby 2nd is not
right, either.
ALL unary operators have precedence higher than ANY binary operator,
while the precedence among unary operators is non-essential.
So, Table 4-4 gives erroneous precedence for ~& and ~| UNARY
operators placing them where such BINARY operators should have
been had they existed. It is still to be determined whether
binary ^~/^ has the same precedence as & (T&M) or lower (IEEE
Draft), and that can be easily accomplished with Verilog-XL
which I'm going to do shortly.

Regards to all,
Sergei Sokolov

[m...@apprentice.silicon-sorcery.com]

Gerard M Blair <ger...@ee.ed.ac.uk> writes:

>
> I am quoting a direct mail to me regarding my last posting
>
> Sergei Sokolov wrote:
> > thank you for the reply. The point of my question was a little
> > broader, namely that the said table does not help you when you want
> > to determine the precedence of two *different* operators, say,
> > unary ^~ and binary &:
>
> > ^~ a & b.
>
> I have trouble answering this (AND NEED HELP PLEASE)
> because:
>
> 1) I think the precedence table is clear in that & has a higher
> precedence than ^~ so that (^~ a & b) == (^~ (a & b))
>

Like most languages, in Verilog, the unary operators all have higher
precedence than any binary operator; indeed the bug is either that any
unary operators are listed in the "Binary Operator Precedence Table"
at all, or that not all the unary operators are listed in the unary
operator column. The ^~ is both a reduction (unary) operator, and a
binary operator; the binary operator table lists it in the correct
place for the binary operator.

--
Michael McNamara Silicon Sorcery <http://www.silicon-sorcery.com>
Get my verilog emacs mode (subscribe for free updates!) at
<http://www.silicon-sorcery.com/verilog-mode.html>

[m...@apprentice.silicon-sorcery.com]

Mitchell Perilstein <mperi...@miworld.net> writes:

>
> Gerard M Blair wrote:
> > So - is the precedence table incomplete? or is my reading of
> > the draft spec wrong? or is Verilog-XL 9404 wrong?
>

> Who ever said XL corresponds with 1364? The current state of 1364
> pretty much guarantees that no tool can comply.

Which XL? Verilog-XL (despite my efforts at a previous
company) is a living product, which happens to be more and more 1364
compliant with each release.

>
> In fact, for cases where the spec and XL differ, why should an
> industrial tool follow the spec?

Again, which XL? All standardizations efforts which work to
codify a living, yet defacto standard (rather than creating from whole
cloth) run into this issue.

> Who would want to buy an industrial tool that handles Verilog
> differently from XL?

Avant!, Mentor, and Viewlogic to name three.

>
> Mitchell Perilstein
> mperi...@miworld.net

[Mitchell Perilstein]

m...@apprentice.silicon-sorcery.com wrote:
> > Who would want to buy an industrial tool that handles Verilog
> > differently from XL?
>
> Avant!, Mentor, and Viewlogic to name three.

Hmm, aren't those guys all tool builders, instead of tool users?
Okay, maybe I should ask the question I intended!

I should have asked: why would somone involved in a chip design flow

want to buy an industrial tool that handles Verilog differently from XL?

-mitchell perilstein
mperi...@miworld.net

[Chong Guan Tan]

Mitchell Perilstein wrote:

> Hmm, aren't those guys all tool builders, instead of tool users?
> Okay, maybe I should ask the question I intended!
>

Not true !! Not at least in chronologic (now viewlogic) and frontline
(now Avent!). The founders and original designers of these simulators
were super heavy weight Verilog users.

> I should have asked: why would somone involved in a chip design flow
> want to buy an industrial tool that handles Verilog differently from XL?
>
> -mitchell perilstein
> mperi...@miworld.net

There are many reasons that one will want to use such simulator in
parallel with Verilog-XL. The most obvious reason is in discovering
race conditions in a design, and this is why it is impossible to
do a bug-to-bug, Verilog-XL compatible simulator.

tan