Of course, (a) is different than a, because (a) can not appear on the left hand side as a target: (a) = c; Otherwise a and (a) when used on the right hand side in an expression both evaluate to the same value, signedness, and so on. However, they are perhaps too similar, as a and (a) both are subject to the size, sign and real coercion rules of 4.4.1 through 4.5.1. I am late to this discussion, but I am surprised you folks are not already considering using the concatenation operator {a} for this contextual isolation purpose. {a} is already well defined and enshrined in Verilog as a way to hide the interior from the size, sign & real coercions; see section 4.4.1 for the 1364-2001 standard; (which by the way is unchanged section 4.3 of my Verilog 1.1a manual from March 1987). I would suggest we define for this new purpose the meaning of {a}[4] and {a+b}[6:0] and hence also {a[3:5],d[1:10]}[5:2] and so on for this purpose, so we don't need to introduce special rules that protect the inside of a expression enclosed by parenthesis only when it is also subject to a bit or part select operation. The concatenate already is well defined to be a self determined expression which evaluates its "arguments" with out regard to the width of the rest of the expression in which it occurs, and it also is already defined to return an unsigned value, again, what you want if you are going to select bits and parts of the entity. Further, use of the concatenate on the left hand side is also already well defined, so you could consider defining the meaning of a left hand side part select of such a concatenate. {a,b} = c; {a,b}[3:1] = c; {a+b} = c; // this one we still must disallow (unless as a constraint!) As for functions, - again, concatenations of functions is already well defined (see section 4.1.4; a function is used inside the concatenate to motivate the replication concatenation), so by extension Arturo's example becomes always @(clk) instr = {f()}[8:2]; would be perfectly natural, and unsurprising to the experienced Verilog user. So, in summary I dislike the introduction of a $select system function as being unnecessary extra typing, and introducing a redundant extra way to do something; I also dislike introducing the ability to do bit or part selects of parenthetical expressions, because we would have to add new rules that would protect these from the existing width, sign and realness expansion. The concatenate operator is already well defined to protect its interior from the context, and can have inside all of the types of expressions you would like to bit or part select, and can appear on the right or left hand side of an expression - its the right choice. Vote concatenate!!!! -mac ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Arturo Salz Sent: Tuesday, March 06, 2007 9:53 AM To: Bresticker, Shalom; Feldman, Yulik; sv-bc@eda.org Subject: 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 <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 Mar 6 14:07:05 2007
This archive was generated by hypermail 2.1.8 : Tue Mar 06 2007 - 14:07:19 PST