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, and is believed to be clean.Received on Tue Feb 20 06:03:19 2007
This archive was generated by hypermail 2.1.8 : Tue Feb 20 2007 - 06:03:27 PST