Re: [sv-bc] Errata in SV 3.1 BNF for unique/priority if...else


Subject: Re: [sv-bc] Errata in SV 3.1 BNF for unique/priority if...else
From: Greg Jaxon (Greg.Jaxon@synopsys.com)
Date: Tue Sep 02 2003 - 11:44:41 PDT


Stuart,

     I don't think there is a discrepancy - the BNF is necessarily more
liberal in what syntax it allows.

     Consider the following example:

  always_comb
  if (operational_mode != four_function_calculator) y = opcode;
  else unique if (opcode == 0) y = a + b;
         else if (opcode == 1) y = a - b;
         else if (opcode == 2) y = a * b;
         else y = a / b;

Here the claimed uniqueness only applies to one arm of the outer if statement.

Stuart Sutherland wrote:
> All,
>
> There seems to be a discrepancy in the 3.1 LRM regarding the use of
> unique and priority with if...else...if statements.
>
> My understanding is that the correct usage is:
>
> always_comb
> unique if (opcode == 0) y = a + b;
> else if (opcode == 1) y = a - b;
> else if (opcode == 2) y = a * b;
> else y = a / b;
>
> This style matches the examples in section 8.4 of the final SV 3.1 LRM,
> and conforms to the text in that section which states:
>
> "The unique and priority keywords apply to the entire series of
> if...else...if conditions...it would have been illegal to insert either
> keyword after any of the occurrences of else."
>
> The BNF in that same section, however, shows:
>
> if_else_if_statement ::=
> [ unique_priority ] if ( expression ) statement_or_null
> { else [ unique_priority ] if ( expression ) statement_or_null }
> [ else statement_or_null ]
>
> According to the BNF, unique or priority can come after each else
> statement in the if...else...if series. Does the BNF mean that the
> example above either can be, or must be, written as:
>
> always_comb
> unique if (opcode == 0) y = a + b;
> else unique if (opcode == 1) y = a - b;
> else unique if (opcode == 2) y = a * b;
> else y = a / b;

Claiming uniqueness here is not conceptually wrong.
At worst it seems harmlessly redundant.
Should this be considered "illegal"?
Redundancy is sometimes a welcome thing.

My conceptual difficulty with BOTH of the above examples
is understanding what should guard the statement list of
the final ELSE. The guard condition on "y=a/b;" has to be
be !( opcode==0 || opcode==1 || opcode==2 ). To construct
this do I ascend the decision tree to the "last" unique
claim? Or do I ascend until the innermost? What do I do
with a tree written in height-balanced form? Uniqueness
doesn't extend to tests made in the "THEN" arm of a conditional...

I have no conceptual problems with switching between priority
and unique semantics along different arms of a decision tree, either.

Repeating the "priority" keyword in an else if chain also seems
harmlessly redundant. Every conditional expression to which "priority"
should apply must survive as either a positive or negative guard on
the statements of the decision trees in its TRUE and FALSE arms...
Reinforcing this by having the keyword "priority" on the same line as the
test condition seems OK to me.

I think the text (section 8.4) suggesting that is illegal is mistaken.
These are my personal preferences as a language designer - unrelated
to Synopsys' products or standardization preferences.

Greg Jaxon

> IMHO, the description in section 8.4 is correct, and the BNF is wrong.
> Please let me know which example above is correct.
>
> Stu
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland-hdl.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
>
> Sutherland HDL, Inc. -- Training Engineers to be Verilog, SystemVerilog
> and VHDL Wizards! www.sutherland-hdl.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



This archive was generated by hypermail 2b28 : Tue Sep 02 2003 - 11:46:40 PDT