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

Perhaps the issue would feel less contentious if the syntax was
reversed so that it resembles function call more than part select:
     [5:3](b & c)    rather than (b & c)[5:3]

Function argument lists are already self-determined expressions.

Greg Jaxon
Disclaimer: JMHO; not an official position...

Feldman, Yulik wrote:
> Currently, part selects are considered a special kind of an “operand”. 
> Consequently, they can only select parts of nets and variables. It seems 
> to me that this definition unjustifiably limits the full design 
> potential of this construct.
> 
>  
> 
> I would like to propose to make part selects operators and to allow them 
> to select parts of arbitrary expressions. This will make possible for a 
> designer to access individual bits of an expression without introducing 
> artificial temporary variables. Consider, for example the following code:
> 
>  
> 
> bit [5:0] a, b, c;
> 
> bit [5:0] t;
> 
> t = b & c;
> 
> a[3:2] = t[5:3];
> 
>  
> 
> If part selects could select arbitrary expressions, the same logic could 
> be rewritten without the usage of the temporary variable “t” and without 
> the need for a separate assignment:
> 
>  
> 
> bit [5:0] a, b, c;
> 
> a[3:2] = (b & c)[5:3];
> 
>  
> 
> The SystemVerilog language has a comprehensive set of operators, 
> allowing the designer to code almost arbitrary logic in a single 
> expression. Unfortunately, the semantics of expressions like “(b + 
> c)[5:3]” or “f()[5:3]” can not be currently expressed in a stand-alone 
> expression. To make a selection of a part of an arbitrary expression, 
> which is conceptually a very simple operation, it is required to 
> introduce a variable and an assignment, despite the fact that most of 
> other, much more complex, logic could be easily represented as a single 
> expression, if needed. If part selects on arbitrary expressions would be 
> allowed, a major hole in the expressiveness of SystemVerilog expressions 
> would be closed.
> 
>  
> 
> Aside helping the designers to write a more compact code, such feature 
> would make the life much easier for automatic tools that do static 
> analysis and transformation of the SystemVerilog code. Such a tool may 
> encounter an assignment like:
> 
>  
> 
> a = b + c;
> 
>  
> 
> And decide, for various reasons, to split the assignment to two parts:
> 
>  
> 
> a[5:4] = (b + c)[5:4];
> 
> a[3:0] = (b + c)[3:0];
> 
>  
> 
> With an ability to select arbitrary expressions, such a transformation 
> would be trivial and would preserve the compactness and structure of the 
> original representation. However, with the current definition, the tool 
> would need to introduce a temporary variable and an assignment, 
> affecting the compactness and readability of the generated code.
> 
>  
> 
> One side note w.r.t. the proposed enhancement is that there is a need to 
> define the exact data type of each expression, instead of defining the 
> “size” (“bit length”) only. In most cases, it should be enough to define 
> the return value type as a packed array of size corresponding to the 
> “size” as it is currently defined, with [size-1:0] bounds. A few 
> operators, such as the type cast operator for example, will need a 
> different definition. In general, SystemVerilog’s type operator already 
> seems to assume that each expression has a well-defined data type (such 
> that, for example, “$left(t)” on “var type(a+b) t;” is meant to have a 
> well-defined value), however, I don’t see such a definition in the language.
> 
>  
> 
> I will be glad to hear comments on this proposal from the committee members.
> 
>  
> 
> Thanks,
> 
>             Yulik.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.


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