Subject: Re: [sv-bc] Alternative to unique/priority if...else
From: Jim Lewis (Jim@SynthWorks.com)
Date: Wed Sep 03 2003 - 11:33:16 PDT
I do not think the unique clause is relevant in either
of the following examples:
>> 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;
>>> 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;
Opcode is an encoded object. Hence, each value must be mutually
exclusive (independent) from the others.
By the way operation_mode is used and the fact that opcode == 3
is not specified, operation_mode is required to have priority
over opcode.
For VHDL-200X + 1076.6 (VHDL RTL synthesis standard) I am thinking
of something like the following pairing to address the simulation
and synthesis aspects of priority issues.
assert one_hot(Op1, Op2, Op3, Op4) report "Error: Expecting onehot" severity error ;
Y <= a + b when Op1 = '1' else
a - b when Op2 = '1' else
a * b when Op3 = '1' else
a / b when Op4 = '1' ;
The power of this methodology will become more apparent
when the expressions have separate pieces that are mutually
exclusive. It can also be applied to case statements.
This is very similar to your old priority avoidence solution
except now the mechanism is checked in the simulator.
Cheers,
Jim Lewis
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter Flake wrote: > 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 - 11:35:18 PDT