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

Shalom,

 

I have to agree with Yulik on this. Put aside expressions for a moment
and consider taking a slice of the return value of a function:

 

            function bit [16:1] F; ... enfunction

            reg [5:0] instr;

 

            always @(clk)

                 instr = F()[8:2];

 

The function call is a self-determined context, so there are no
ambiguities as to what the semantics of the above ought to be - in fact,
I've seen some examples where designers tried to do as much - and yet,
the above syntax is not allowed. If we were to extend the language to
allow slices of function calls, i.e., primaries, it wouldn't be too much
of a stretch to consider expressions as well. Allowing slices of
expressions would entail creating special rules that would create a
self-determined context and a default indexing scheme, but, I don't
believe such rules would be too outlandish.

 

Finally, I have a problem with the system function approach - $select()
- because it's not possible to write the prototype of the function,
i.e., what's the type of the return value. Users wouldn't be able to
write this functionality via a PLI function. Hence, this system function
is really a new syntactical construct that would have to be recognized
by compilers. So wouldn't it make more sense to use actual syntax to
denote as much.

 

            Arturo

 

________________________________

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, March 06, 2007 5:28 AM
To: Feldman, Yulik; sv-bc@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.
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.

 

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 <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.