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

I would expect the operands of the part select to be self-determined.
W.r.t. the "equivalent behavior", I won't really expect such a behavior,
since the part select operator will be a new construct in the language,
which should be expected to have its own rules. In particular, if you
refer to the example with splitting an assignment to two, and a
situation where the LHS is wider than RHS, I would expect the tool to
detect it and make the corresponding adjustments prior to applying the
part select operator (either by explicitly inserting zero/sign
extensions in form of concatenations wherever needed, or just by using
the contemporary approach with the temporary signal). Generally, I would
expect designers to have a linting rule that would prohibit having
assignments with LHS wider than RHS, since this is more often a sign for
a bug, rather for a conscious usage of the language feature.

--Yulik.

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Tuesday, February 20, 2007 5:23 PM
To: Bresticker, Shalom
Cc: Feldman, Yulik; sv-bc@server.eda.org
Subject: Re: [sv-bc] part selects on arbitrary expressions

My concerns would be that unless you make the expression on which
the select operates a self-determined expression, the behavior
is going to be, perhaps, surprising.  If you do make it self
determined, it might be even more surprising since the
equivalent behavior that Yulik appears to want would not necessarily
hold.  I suspect that there are some surprising edge cases
in either choice which makes me pretty hesitant to do this.

Gord.

Bresticker, Shalom wrote:
> See Mantes 1197 (and 618).
> 
>  
> 
> I would be happy to see this, if it could be defined clearly and the 
> risk of errors minimized.
> 
>  
> 
> Shalom
> 
>  
> 
>
------------------------------------------------------------------------
> 
> *From:* owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]

> *On Behalf Of *Feldman, Yulik
> *Sent:* Tuesday, February 20, 2007 4:03 PM
> *To:* sv-bc@server.eda.org
> *Subject:* [sv-bc] part selects on arbitrary expressions
> 
>  
> 
> 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* <http://www.mailscanner.info/>, and
is
> believed to be clean. *

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com

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