Subject: Re: [sv-bc] Errata in SV 3.1 BNF for unique/priority if...else
From: Peter Flake (Peter.Flake@synopsys.com)
Date: Wed Sep 03 2003 - 04:55:00 PDT
Greg,
Surely the "unique" is part of a statement_or_null, rather than the top "if".
I think that the BNF quoted by Stu is not only ambiguous, from the
implementation point of view, but misleading to a user because it suggests
that the "unique" can occur otherwise than before the first "if".
Peter.
At 11:44 02/09/2003 -0700, Greg Jaxon wrote:
>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 : Wed Sep 03 2003 - 05:07:46 PDT