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

Or consider the similar case of

module test;
longint long[4];
initial
begin
  long = {-1,-1,-1,-1};
  $display(long[1]);
end
endmodule

I think users would be surprised if long[1] doesn't come out -1.  If you evaluate the operands in the context of an assignment to a longint, then it will.  If you evaluate it in a self-determined context, then it might come out as 4294967295 (i.e. 64'sd0ffffffff).  It would depend on what rules you applied when converting the value of the self-determined expression to the type of the LHS.  Such rules would have to be specified, since there isn't a precedent.  Why would we do that, rather than just specifying that the operand is evaluated in the context of an array 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.