RE: [sv-bc] part selects on arbitrary expressions

Since this discussion has got rather lengthy, and may be difficult to
follow, so I would like to summarize the main points that were discussed
and my personal understanding of the outcomes of the discussion:

 

*         There is no general objection to this language enhancement.

*         It is already captured in 1197.

*         The "first operand" of the part select (representing the
object being selected) should be self-determined.

*         The existing part select syntax with brackets and dots is more
flexible than the alternative syntax with system functions.

*         It is important to allow part selects to operate on operands
that have complex data types, and consequently to let part selects to
return complex data types themselves. 

*         The alternative modeling approaches using shift operators and
concatenations are not applicable to complex data types, and thus are
not really suitable.

*         The language currently doesn't define the exact data types of
expressions (it only defines the bit size and signedness). This
definition is important for sound definition of part selects on
arbitrary expressions. 

*         SV's array query system functions already assume that the data
types of expressions are fully defined, and thus the absence of such
definition is a hole in the current specification (independently of part
selects).

*         Examples of expressions that may return complex data types are
identifiers, part selects, cast operators, assignment operators,
conditional operators and possibly other kinds of expressions.

*         For expressions other than expressions that return complex
data types (i.e. for most existing operators), an appropriate definition
of their data type would be a "normalized" one-dimensional packed array
with [N-1:0] bounds, where N is the bit size of the result.

*         Allowing a part select on another part select is a handy
feature, which, in particular, may be useful to resolve the currently
existing LRM's ambiguity of passing part selects as arguments to
property instances.

*         The parenthesis "()" in Verilog is a kind of syntactic
sugaring, in a sense that the type of the ()'s "result" is always
exactly the same as the type of its "operand". The "operand" of () is
always context-determined. 

*         The syntax of (expr)[a][b][c] for the part select operator
(where the parenthesis may be optional for certain kinds of selected
expression) seem to be the most succinct and flexible syntax suggested,
even though several committee members raised concerns about ability of
an uninformed reader to infer that the "first operand" of the part
select given in such syntax ("(expr)") is self-determined. 

 

--Yulik.


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