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] *On Behalf Of > *Gordon Vreugdenhil > *Sent:* Thursday, July 24, 2014 6:13 PM > *To:* Steven Sharp; Greg Jaxon; 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 Graphicsgordonv@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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jul 24 22:18:49 2014
This archive was generated by hypermail 2.1.8 : Thu Jul 24 2014 - 22:18:56 PDT