As usual: open a new Mantis issue and wait for the next revision to deal with it. From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] Sent: Friday, July 25, 2014 10:27 To: Bresticker, Shalom; Mark Hartoog; Gordon Vreugdenhil; Steven Sharp; Greg Jaxon; sv-bc@eda.org Subject: RE: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation I came to the same conclusion as Shalom. I interpreted the rules as Gord and Dave, but it is evident from Steven Sharp's reasoning that the LRM left enough room for different interpretations. The big question is: now that have ambiguity and possibly divergent implementations, how do we deal with this? Arturo From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom Sent: Thursday, July 24, 2014 11:03 PM To: Mark Hartoog; Gordon Vreugdenhil; Steven Sharp; Greg Jaxon; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: RE: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation I think the discussion proves the ambiguity. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Mark Hartoog Sent: Friday, July 25, 2014 08:58 To: Gordon Vreugdenhil; Mark Hartoog; Steven Sharp; Greg Jaxon; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: RE: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation The nested form is disallowed because the rules of section 10.10 require a self-determined type. The self-determined type is needed to decide if a UAC item "represents" a single array element or the item is an unpacked array and the elements of its slowest varying dimension represent as many array elements as exists in that item. A UAC does not have a self-determined type, so there would be no way to decide which of the two rules of section 10.10 applied to it. From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Thursday, July 24, 2014 10:18 PM To: Mark Hartoog; Steven Sharp; Greg Jaxon; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: Re: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation So if the assignment is context determined, why does 10.10.3 disallow nested forms? I wouldn't claim 4'bxxx1 is correct. I'd interpret the rules to be two steps -- the elements are self-determined and then assigned. So you would get the effect of "element = 1'b1" or 4'b0001. If you want to claim that the assignment is context determined, the restrictions (and even why this was ever defined rather than just an aggregate) becomes a serious question. Gord On 7/25/14, 9:45 AM, Mark Hartoog wrote: I disagree that 10.10.3 is "pretty clear about the implications of unpacked array concat elements being self-determined". What 10.10.3 says is: "Each item of an unpacked array concatenation shall have a self-determined type (see 10.10), but a complete unpacked array concatenation has no self-determined type." There is a difference between requiring an expression to have a self-determined type and requiring it to be evaluated in a self-determined context. You can determine the self-determined type of an expression without evaluating it. In my opinion sections 10.10 is unclear about how unpacked array concat (UAC) item expressions are evaluated. <LRM> ...each item shall represent one or more elements of the resulting array value, interpreted as follows: - An item whose self-determined type is assignment compatible with the element type of the target array shall represent a single element. .... The elements thus represented shall be arranged in left-to-right order to form the resulting array. </LRM> This section of the LRM uses the term "represent," which I don't think is defined. The items of the UAC represent the elements of the array, but there is no discussion of how the expressions in the elements are evaluated and transferred to the array elements. If the correct result is 4'b0001 in this case, then the expression was evaluated in a self-determined context and then assigned to the array element using the normal rules for assignment. If the correct result is 4'b1111 then the expression was assigned to the array element and evaluated using the normal rules. I see no text in the LRM that says either of these is correct. If the '1 expression evaluates to 1'b1, then why isn't the correct result 4'bxxx1. What text in the LRM requires the zero extension? Apparently everyone thinks there is an assignment to the array element taking place that follows the normal assignment rules because no one has suggested 4'bxxx1 is the correct result. Why does the expression evaluation take place before that assignment? I don't see any text in the LRM that implies that. Just saying the expression must have a self-determined type does not imply that it must be evaluated in a self-determined context. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil Sent: Thursday, July 24, 2014 6:13 PM To: Steven Sharp; Greg Jaxon; sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: Re: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation 10.10.3 is pretty clear about the implications of unpacked array concat elements being self-determined. The key implication is that they don't nest (since there is no "type" for the inner element). I don't want to just assume there entire discussion is also just accidental wording. The implications of the ambiguity between regular concats and unpacked array concats in various contexts is pretty bad already and not having the elements be self-determined certainly a rule change. Both 10.10 and 10.10.3 are very clear that the elements are self-determined and are clear about the implications of that. Gord On 7/25/14, 5:22 AM, Steven Sharp wrote: I don't see any reason to believe that UAC operands are evaluated as self-determined, just because vector concatenations are. They are different operators, with different properties in the specific areas that influence how their operands should be evaluated. The entry in Table 11-21 for {} was intended for vector concatenations, not UACs. Even if we didn't know the history of that table entry, we could tell that it cannot apply to UACs. It lists a bit length for the expression, and a UAC does not have a bit length because it is not an integral/vector value. So the LRM doesn't say anything about how operands of a UAC should be evaluated. As Daniel says, the text about an item's self-determined type is just a rule to determine whether the item provides a value for a single element or not. Greg suggests that it wouldn't talk about the self-determined type if you were not supposed to evaluate it that way. But that is just a matter of the wording chosen. It could have been worded more simply by saying that the item is assignment-compatible, without the text about self-determined. I don't think there is any difference. It is just a case of somebody getting carried away with the wording. The existing text about assignment compatibility in other cases could have been written to say that an expression is assignment compatible with a left-hand side if its self-determined type is assignment compatible. That wouldn't affect how the expression was evaluated. What should be considered here is not the accidental wording used in that rule, but the properties of the operator. When doing an assignment, Verilog never evaluates in a narrow context and then widens the result. It always propagates the wider context down into the expression and evaluates at that wider width. This is deliberate, to avoid overflows of intermediate results. This '1 case is effectively an example of that. If it were being assigned to a single element, it would be evaluated at the wider width. Doing it as an aggregate should not change that. Evaluating it at a narrower width would effectively truncate the result, as with an overflow. The only times Verilog calculates something and then widens it are cases where there is no way to propagate the width down into the operand and calculate it at the wider width. In this case, there is no difficulty with propagating the width of the element into the operand expression. For consistency with the rest of the language, operands that correspond to a single element should be evaluated as context-determined expressions in the context of an assignment to a single element. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon Sent: Thursday, July 24, 2014 2:09 PM To: sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: Re: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation The prose could be more definite, it would have been written better had it been intended as the first case ever where SV figures-out the self-determined type and then context-determines the bit-width of the assigned expression. Everywhere else, when the LRM is being clear, it picks one or the other of these treatments. Imagining that they'd combine without some special mention of that unique fact seems more like a willful misreading than an outright ambiguity. As Dave Rich hinted, having A='{'1} and A={'1} set A[0] to 4'b1111 and 4'b0001 respectively is not the worst outcome. Bit-width context dependence does not ordinarily penetrate concatenation braces. In the case of UAC, something less than the full type information is getting through - only unpacked structure is inherited. On 7/24/2014 5:15 AM, Bresticker, Shalom wrote: It appears to me that Daniel is correct that the LRM is ambiguous about this. From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek Sent: Thursday, July 24, 2014 10:08 To: Rich, Dave Cc: Goel, Rohit (Noida MED RTLC Synthesis); sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: Re: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation I'm not sure if Dave's interpretation comes from explicit LRM rule. LRM for says only that UAC: elements shall be interpreted as : "An item whose self-determined type is assignmentcompatible with the element type of the target array shall represent a single element" but does not say how assignment should be performed. IMHO each element assignment should be done according to general SV rules so A[0] would be 4'b1111 according to Dave interpretation special assignment similar to vector concatenation should be done. Maybe I'm missing something but imho this case is in grey/undefined area of LRM. I think that rule cited above was added to define cases where element by element assignment are possible vs cases other cases possible in UAC, not to define assignment rules DANiel W dniu 7/23/2014 4:25 PM, Rich, Dave pisze: The operands in an unpacked array concatenation are self-determined, just like Verilog integral concatenation. So 1'b1 should be the result. Assignment patterns are context determined. This is one of the key distinctions between the two forms. Dave From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Goel, Rohit (Noida MED RTLC Synthesis) Sent: Wednesday, July 23, 2014 3:49 AM To: sv-bc@eda.org<mailto:sv-bc@eda.org> Subject: [sv-bc] Clarification for `1 usage in unpacked array concatenation In SV 1800-2009 concatenations could be used as source expressions for unpacked arrays (section 10.10). I have a query regarding usage of `1 in unpacked array concatenation. If the RTL has something like below logic [3:0] A [0:0]; initial begin A = {'1}; end Does this mean that the value of A[0] after assignment will be "1111" or will it be "0001"? Thanks & Regards Rohit Goel -- 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<http://www.mailscanner.info/>, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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<http://www.mailscanner.info/>, and is believed to be clean. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Verification Technologies, Mentor Graphics gordonv@model.com<mailto:gordonv@model.com> -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Verification Technologies, Mentor Graphics gordonv@model.com<mailto:gordonv@model.com> -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Jul 25 00:35:11 2014
This archive was generated by hypermail 2.1.8 : Fri Jul 25 2014 - 00:35:29 PDT