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