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

 

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.

[Yulik] Defining the type of (a) as [5:2] (i.e. the type of "a") seems
to me a natural choice. Once defined, I don't think it should be complex
to remember (that the type of () is exactly the same as the type of the
operand). This also must be the current intention of the LRM, even
though it is not clearly defined.

 

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.

[Yulik] Maybe you should look on it differently: the operand of () is
always context-determined, and the "first operand" of [3] (the
expression on the left of it) is always self-determined. It is easy to
define and remember. In fact, I'm a bit surprised that this issue of
self-determination of the "first operand" of the new operator created
such a big debate. For some reason, it looks to me very trivial to
understand that anything on the left of [] is self-determined, once it
is defined to be so.

 

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.

[Yulik] Unfortunately, in my experience, the cases when the part select
is needed on complex data types are quite frequent. For me, a solution
that will not account for complex data types will not be really a
solution.

 


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