RE: [sv-bc] RE: Clarification for `1 usage in unpacked array concatenation

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] On Behalf Of Greg Jaxon
Sent: Thursday, July 24, 2014 2:09 PM
To: 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, and is
believed to be clean.