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

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Tue Feb 20 2007 - 06:14:11 PST
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, and is
believed to be clean.
Received on Tue Feb 20 06:16:12 2007

This archive was generated by hypermail 2.1.8 : Tue Feb 20 2007 - 06:16:25 PST