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

Your point about the limitations of $select is well-taken.

 

However, I still think there are problems with parentheses. 

For example, today "(a)" is treated semantically like "a". 

For example, if a is of type 'logic [5:2]", then $left(a) gives 5 and so
does $left((a)).

Similarly, if a is of type 'enum logic {ZERO,ONE}', then "a = (ZERO);"
is legal, just as "a = ZERO;" is. 

I'm not sure that it is clear from the LRM that it should work that day,
but that is what I have seen in the tools in practice.

 

So for example, if we would allow (expr)[3], then when would "expr" be
considered [N-1:0]?

Today, if a is [5:2], then "(a)" is also [5:2], and not [3:0].

So that is one ambiguity.

Even if it would be defined in the LRM clearly, it becomes a "gotcha",
as Stu calls it, a pitfall, where people are going to become confused,
and we put a stumbling block in their paths. We need to remember that we
deal with human beings. Human beings are those who need to read and
write this language.

 

Similarly, the question of when "(expr)" is context-determined and when
it is self-determined. If in "(expr)[3]", it becomes self-determined,
then it is going to confuse people and be a gotcha.

 

From those points of view, using concatenations, i.e., allowing
bit-selects and part-selects of concatenations, is much less ambiguous.
It is only a partial solution, in that it would only deal with 1-D
arrays, but that is in my experience the main case where it is needed,
and it would not prevent allowing in the future selects on a different
syntax. It would only be an extension of an existing syntax without
preventing extending other syntaxes in the future.

 

Shalom

 

________________________________

From: Feldman, Yulik 
Sent: Tuesday, March 06, 2007 4:01 PM
To: Bresticker, Shalom; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

 

 

________________________________

From: Bresticker, Shalom 
Sent: Tuesday, March 06, 2007 3:28 PM
To: Feldman, Yulik; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

For example, "$select(a+b,3,3)" makes it clear that a+b is a
self-determined expression, and the subscript/index 3 relates to that. 

[Yulik] You will get into serious problems with this syntax if the type
of the selected expression is not going to be a simple one-dim array. In
some cases, it will be advantageous to have such types. A trivial
example is (a)[3], but you may say it is redundant. A more complex
example is a part select over part select: (a[3])[4], which may come in
handy in Dmitry's example and other situations. Another example may be
the conditional operator: (c ? a : b)[3]. I would say that if "a" and
"b" both have the same type, it may be nice if the type of the
conditional operator would be the same, and not converted to the one-dim
array. If the type of the selected expression is not a simple one-dim
array, then you will need a variable number of arguments for the
selections, and you will need a way to distinguish between a bit/part
select and the member select (not mentioning that a reference to a
member as an expression will be illegal in the $select(<>, member)
syntax). In these situations, using the existing syntax of part select
will be much more convenient than introducing a new syntax, like the one
with the operands of a system function.

 

Moreover, the existing part select syntax provides you an option to
specify a bit select (a[3]), a part select (a[4:3]) or a
ascending/descending part select (a[3+:4], a[3-:4]). This is also quite
handy, and won't be directly available with the syntax above
($select(a+b,3,3)).

 

Otherwise, you get into questions such as whether a and b are
bit-extended and/or type-converted before the bit/part-select is
performed.

[Yulik] I don't think it will be difficult to apprehend that the "(a+b)"
operand of "(a+b)[3]" is self-determined, once it is defined clearly in
the LRM and people get accustomed to it. I understand that it may be not
intuitive from the first glance, but after all we're talking about a new
construct, and its semantics doesn't have to be 100% clear for the one
who never looked on the definition of the construct in the LRM. Compared
to the syntactic issues of the system function approach, it seems to me
a minor issue.

 

Shalom

 

________________________________

From: Feldman, Yulik 
Sent: Tuesday, March 06, 2007 3:20 PM
To: Bresticker, Shalom; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

Hi Shalom,

 

I agree with everything you have said here, but I didn't understand what
led you to conclude that adding a system function is better than not
adding it. To me, "(a+b)[3]" is simpler to write and to read than
"$select(a+b)[3]" (or whatever the syntax), and I don't see any
substantial problem with allowing the "(a+b)[3]" (as well as "(a)[3]"),
as I argued in the previous posts. Since it is a new construct, the
semantics of "(a+b)[3]" may be defined in any appropriate way, including
the one that would match the supposed semantics of the system function.
However, syntactically, "(a+b)[3]" will be simpler to write and read,
and this is why I think it is better than the system function.

 

--Yulik.

 

________________________________

From: Bresticker, Shalom 
Sent: Tuesday, March 06, 2007 2:46 PM
To: Feldman, Yulik; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

Hi, Yulik.

 

I don't agree. The parentheses turn the identifier inside into an
expression.

[Yulik] I'm not sure I follow you. In my eyes, an identifier placed in a
syntactical context where an expression is expected is an expression,
even if it not surrounded by parenthesis.

[SB] "a" is an identifier. As such, it can be a primary or an
expression. Today, only an identifier can be followed by a bit-select,
not a general primary or expression. When you put parentheses around the
identifier, it is now an expression and a primary, but no longer an
identifier, and therefore cannot be followed by a bit-select.

 

 So a[2] is legal, whereas today a[2] is not. 

[Yulik] Apparently, you forgot to put the parenthesis in one of these,
so I'm not sure what exactly you meant.

[SB] Apparently I meant that a[2] is legal, whereas (a)[2] is not legal
today.

 

(a) is not the same as a, it is an expression whose value and, to a
certain degree, type are the same as those of a.

[Yulik] What exactly the differences are and where it is defined in the
LRM? I understand that sometimes the syntax requires the presence of
parenthesis to avoid ambiguities, but I see that as a purely syntactical
issue; not semantic. To be more exact, I expect both the value and the
type of the "parenthesis expression" to be exactly the same as those of
its "operand" (not "to a certain degree"). If you show an example where
this is not the case, I would agree that the parenthesis have a special
semantic meaning.

[SB] Maybe it does have exactly the same type. But that very syntactic
difference is today what prevents directly taking bit-selects from it.
The difference is again that the case where the parentheses enclose only
a simple identifier is a special case. In general, the parentheses can
enclose a complex expression.

 

Overall, I came to the conclusion that I liked Dmitry's suggestion best,
of adding a system function to do this.

 

Shalom

 


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